In a previous post, I tackled a question from an architect friend of mine about whether it was possible to have anything worth releasing in just three iterations. In this post, I want to answer another question from the same conversation:
When we are building software with a traditional phased approach, we have a lot of time to think about design. How do we avoid bad design if we are moving so quickly?
When you’ve been part of the Big Design Up Front school, you try to anticipate all requirements that may come your way and design for them up front, completing the design of the software before development begins. The problem with this approach is that you end up with a lot of code that you do not need, for a lot of anticipated requirements that never came to fruition, or were removed from scope as the project progressed.
When I was having this conversation with my architect friend, he assumed that I was going to propose an alternative of no design up front, but of course this approach is worse than BDUF. Let me say that more succinctly:
For anything other than the most trivial of projects, too little design is worse than too much design.
If you don’t think about design at all up front, the best outcome you can expect from your project is a mish mash of features that probably do not hang together as a product. Your most likely expectation is to throw away lots of code and have a dead ends and false starts.
So how much design is enough design? The ideal approach is first to think about the end game for the project. What is the vision for the product / project? What would that look look like (at a very high level)? If your customer expects some upfront specifications, spend the time to create a short document using the Big Picture documentation pattern, as described in Agile Documentation by Andreas Rueping:
Problem: How can people be introduced to a project without being confronted with a deluge of technical details?
Solution: A good feel for a project is best conveyed through a description of the “big picture” of the architecture that underlies the system under construction.
Andreas goes on to describe the documentation pattern as describing the overall architecture, showing how the system is composed of subsystems and modules and explains the basics of the system’s behaviour. It also explains the design principles and the motivations that led to the design, as well as naming the technologies involved in the design. Most importantly, it abstracts over any details, technical or otherwise, that are irrelevant to an overview.
For detailed design, think about what is in the current iteration, and what you expect in the next iteration (some people call this the back burner iteration), and design for that. This is just enough design. Document your design using a wiki, and keep really detailed function and module level documentation in the tests where it belongs.
When designing for an agile project, you will always be walking the tightrope between too much and too little design. It’s a scary place to be at first.
When you fall off on the too little design side you will either have a patchwork quilt of requirements that are not a product, or you will throw away code and have dead ends.
If you fall off on the too much design side, you will end up with lots of detailed design, code and dollars spent on requirements that are no longer needed.
I never said this was easy – this is why we earn the big bucks, right? But, just like a tightrope walker, actually getting up there and falling off a few times will make you better at it in the long run. Over time, you will become the Maria Spelterini of Agile design.