Evolution of Architecture as a Drunkard’s Walk
Friday, July 21st, 2006One of the tenets of many Agile Development approaches is that the system’s Architecture evolves over time. The claim being that the architecture will remain optimised for the systems purpose and will be easy to understand because it doesn’t have a load of hooks and parameterisations to allow for unspecified requirements. Extreme Programming has some aphorisms to emphasise this: DTSTTCPW (“Do the Simplest Thing that Could Possibly Work”) and YAGNI (”You Ain’t Gonna To Need It”) spring to mind. Martin Fowler’s article Is Design Dead is one of the classic descriptions of how it should work.
Agile developments have an imperfect memory, with little historic documentation it is reasonable to view each architectural decision as being made using the current system architecture and requirements as the only inputs. That being the case then the evolution of the architecture can be seen as a Markov Chain or Drunkard’s Walk (at least metaphorically).
What does this mean? The ideal architecture is as described above simple, and focused, it should also be balanced and not restrict you from taking it in any a particular direction. This last desirable trait is invisible, you don’t know you cannot go in a particular direction until you try to go there.
It is inevitable that each change you make to the system takes you off the ideal “balance” point for taking the architecture off in an, as yet unspecified, new direction. You might feel that as each requirement and takes you “off balance” in a random direction then the likelyhood is that, overall, you will stay on balance. This is where the drunkard’s walk comes in, over time a random walk diverges from the centre line, never to return:
Over time your architecture will become less balanced and amenable to change. Getting the balance back will probably require an architectural review of some kind and some kind of more disruptive change than another simple refactoring.