Executable Architecture: Design Must Be Incremental
10/6/2009 8:47:00 AM
Incremental Design vs Complete Upfront Design
No matter how genius humans are, in my view, it is impossible to have a complete design that works perfectly from the first time when innovating a new software or inventing anything for that matter.
We hear the emphasis in real development situations being on implementation to be incremental but we rarely see incremental design being stressed out.
Increments must always be created twice: once in design and once in implementation. Why design? Design simply means think. Think, then execute. It is as simple as that. On one extreme, some developers got it backwards. They jump straight into coding first, then they think about it, afterwards, if they even do that. On the other extreme end, you got the ones who think about the total design first, bordering analysis-paralysis, then totally execute. The correct way is usually in the middle, neither extremes. Think (a.k.a. design) a little, execute a little, then think a little, then execute a little. From my personal experience and observation, this seems to be the optimal approach.
An analogy would be the journey of discovery. It is like entering a dark cave with a flashlight. You can only see (design) a few feet ahead. You don't know all the possible shortcuts or dangers that lie ahead. Every time you walk forward (implement) you might discover new crevices or nooks that you weren't aware of or dangers lurking to avoid.
Similarly, for new product ideas to succeed, the development approach is always a cycle or an iteration: design a little, implement a little, get feedback. Then, take that feedback, add on top of the first design another little incremental design, implement, feedback. Keep repeating until you're satisfied with the results and you achieve the complete work flow or requirement.
Once we have a complete product or we're in post-production, now we can manufacture or "assemble" as many pieces of this design as we want. As you can notice, unlike design, assembly can be planned in one big shot. This is because the design has already been proven to work and we are past the discovery phase.
What is executable architecture?
Having established the above, it follows that since architecture is a design activity, there's no such thing as an initial complete architecture on paper, then complete implementation. This is old style. It doesn't work. Avoid it like the plague. This was where the architect sat on a high pedestal and all he or she did was draw diagrams and hand them down for implementation. This perception of an architect is archaic.
The realistic and most effective way of creating a robust software product is to start with an architecture increment then implement that increment and then repeat as mentioned above. Start with a core architecture that addresses the significant use case scenario. Stop. Implement it. Get the feedback, then add on top of it. To distinguish this architecture from the paper-architecture I like to give it the term Executable Architecture. It can be executed and the results can be observed.
Software Architects: Keep your development skills sharp. The architecture is the actual code not the paper. The main benefit of paper or UML diagrams is to communicate, document and understand the architecture.
