Because Agile software development methodologies place relatively low emphasis on design, little has been written on design reviews.
I personally strongly believe in upfront design (see previous post), and thus design reviews.
To me the same argument can be made about the importance of design reviews as is made for pair programming – and conversely I have a hard time understanding why one would advocate pair programming and not design reviews: “two heads think better than one”.
Any “bug” that can be found during the design phase, will cost a lot less to fix, than if it is found during the implementation phase.
Furthermore, the advice of my peers is most useful to me in the early stages than when I am 95% done. It’s a lot easier to incorporate their suggestions, or explore alternatives, when no code has been written.
In summary, in my view, the best approach is to spend time upfront figuring out the design, and once I have a good idea of what I want to build, to code it using the Agile methodology. In other words: “Think holistically; code-and-test incrementally”
So when should a design review be held?
As a developer, I want to hold a design review when:
- I need help
- I want to confirm that I am on the right track
- I want to double check that I have not missed anything
- I want to communicate some assumptions that I have made that impact other components.
The design review is important not only to validate the design, but also to communicate: what I plan to do, and how it will impact others: developers, as well as testers, and even tech support, documentation, and product marketing
In the next post, I’ll publish a Checklist. Its purpose is primarily as a tool during the design process itself, to make sure that all aspects of the design have been considered. It is also useful during the design review session as a guide for the discussion. Finally, you can infer from the checklist all the people that need be informed about this design, and ultimately the implementation