Twenty years ago, the Agile community asked: Is Design Dead? They answered it wrong.
I've spent fifteen years watching teams build systems using "evolutionary design." Watched them celebrate velocity. Then watched those systems collapse eighteen months later.
The Misreading
Martin Fowler's 2004 essay had prerequisites: skilled developers, comprehensive tests, small systems, teams empowered to refactor.
Organizations adopted "no up-front design" while ignoring everything else. The result wasn't evolutionary design. It was accidental design.
The Scaling Problem
When your system is small, refactoring is cheap. But systems don't stay small.
I consulted for a fintech that embraced "emergent architecture." Two years of fast shipping. Then they tried to add multi-currency support. The USD assumption was everywhere. A one-month feature took eight.
Three Categories of Hidden Debt
Structural Coupling: Your microservices became a distributed monolith with network calls.
Concept Fragmentation: "Customer" means three different things in three services.
Performance Debt: Seventeen database queries for one feature.
The Solution
Before any significant capability, ask:
- What new concepts does this introduce?
- What assumptions are we encoding?
- What will be hard to change?
- Where are the likely extension points?
One team spent one extra day on an architecture spike. Six months later, adding push notifications took three days instead of three sprints.
Bringing Design Back
The Agile Manifesto says "responding to change over following a plan." It doesn't say "no plans."
Evolution without selective pressure produces chaos. In software, that pressure is supposed to be design.
Full article with case studies and implementation checklist at agilelie.com
Top comments (1)
Appropriate Design
youtube.com/watch?v=lNUQIjGe-ec
In this video cira 16 years ago I outline how Agile has a problem. You can't take a shack and add a ballroom. There are shearing layers, where some things are easier to change than others. As with natural selection the agile process result in artifacts of the evolution persisting. New features get budget, reworking the architecture doesn't.
In the Appropriate Design approach the whole system is broken into modules which are described in just enough detail to use for contracts. Then each module is made, each according to the contract, or if you like interface.
Another issue which is pervasive is domain coupling, where the application becomes way more narrow than it needs to be because the database design forces development to code against fixed data structures, rather than being flexible at runtime. Agility by name, but not nature. Instead they solidify around these data artifacts and suddenly you are doing cut and paste API for each individual data structure.
YAGNI is all very well, only there are very common patterns in REST API that don't need to be reinvented every time you write an application. Perhaps writing a more generic flexible and feature complete platform, while taking a little longer, will pay dividends in flexibility and raw development speed.