05 September 2025
My first foray into agile development was twenty-five years ago. Back then, the mantra was the big buzzword was YAGNI — “You Aren’t Going to Need It.” Build exactly what the user asked for, no extras. Why? Because the moment they saw the first version, they’d inevitably want to change it. Seeing their idea come to life on the screen made it real — and that’s when the work began.
We thought we were creating agility by leaning heavily on unit tests, sometimes even writing the tests before we wrote a single line of code. And with that approach we didn’t need the “big design up front” — or BDUF, as we derisively called it. Oh, how clever we were. We could just keep shaping the code as new ideas rolled in.
I confess it was difficult to get the business leaders to buy into the agile approach, it seemed counter-intuitive. To jump into code before fully understanding the whole application seemed like an expensive and risky approach. I would often have to listen to figures presented by stuffy ex-Cobol people about the costs of rework and so on. I spent a lot of my time giving presentations and evangelising this new heretical method that was seen by many to trash the sacred engineering foundations of software development.
We don’t have to evangelise agile methods anymore. Now we have the opposite problem. People are so enamoured with agile they have failed to realise that we have to figure out how to put breaks on it. Okay guard rails then. Agile cannot help emphasising user features, they are after all what forms the basis of the requirements. Schedules are written around the release of features. Kanban boards are shuffled around describing this function and that function and the engineering is just background stuff that the devs need to look after in their own time. Of course, there are teams with good technical leadership that manage to navigate this, but there are also many teams that just don’t. Business stakeholders are left scratching their heads, wondering why suddenly new features are so expensive to add or to change, or why this or that critical feature is still so far off, why it was all green lights until it was red and there is nothing that can be done.
Countless times when I have been asked to have a look at a project, I am presented with a set of requirements set to a timeline. There is no design. Often, when I enquire after the design, I get presented with an architecture which amounts to all of the various technologies that are being used connected with arrows. Those diagrams have their place, but they are insufficient.
In enterprise software a good design is a result of someone spending time conceptualising the application, understanding its boundaries and its moving parts and making sure that they hang together as a whole. This will bring about a shared understanding of the parts, a conceptual architecture that describes how the requirements will be executed in the application. The concepts in the conceptual architecture should not be technical componentry, because to make them so, will kill the shared understanding. From that point on it becomes a problem for the technical guys.
Frederick P Brooks Jr. the author of “The Mythical Man-Month” said that conceptual integrity is the most important consideration in system design. Sadly, this critical output is sometimes neglected or fudged. For the last twenty years, at least for teams that have not quietly covered off this requirement, this has caused multiple problems.
Brooks championed conceptual integrity to prevent fragmented and difficult to maintain systems. Today the problem is bigger, and the stakes are infinitely higher. The conceptual integrity of a system is what enables us to properly secure it. Teams need a complete and unified vision for how a system resists attack. The attack surface isn’t just about exposed endpoints; it’s about every feature, every integration, and every assumption we make about trust.
Without a coherent security design from the start, Agile teams risk sprinting straight into exploitable architectures.
