Evolution of Architecture as a Drunkard’s Walk
One 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.
July 21st, 2006 at 1:37 pm
The XP way to organise a picnic:
http://www.softwarereality.com/rumours/story032.jsp
July 9th, 2007 at 8:11 am
[…] Tom Ayerst pretty much hits the nail on the head. […]
July 10th, 2007 at 7:07 am
[…] About Architectural Evolution July 9, 2007 Posted by Jiri Lundak in Agile, Architecture. trackback Tom Ayerst, whom I met when becoming a Certified ScrumMaster in Vienna in 2004, writes here someinteresting notes about architecture evolution, like: […]
August 2nd, 2007 at 2:48 am
I don’t disagree, but will play devil’s advocate:
why do you assume even likelyhood of drift in both directions? isn’t the agile creed to check the code in better than you checked it out? this implies the drift is more well behaved.
August 2nd, 2007 at 9:13 pm
The problem is you don’t know where the balance point is for a particular new direction is. You don’t know which way you will be asked to go until you are asked.