Thursday, October 06, 2011
Design Reviews as a Worst Practice...
A design review is a typical process in the development of enterprise software where the architect spends time performing knowledge transfer of sage wisdom to the development team. While many believe these ceremonies result in better software, they haven't yet asked themselves if there is a better way...
As an Agilist, I am savage in the pursuit of finding better ways of developing high quality working software. It seems to me that the notion of design reviews fail to acknowledge that there is a significant gap between the architecture diagrams produced by architects and the code written by developers. Even when people were co-located in the same building, their was a strong likelihood of misinterpretation and bad communication. This is only exacerbated when you put Indian IT outsourcing into the mix.
Can we possibly think that a few hours set aside for a review can solve miscommunications either due to the architect not describing their designs clear enough or the developer not being experienced enough to fill in some left-out detail that the architect considers obvious? Independent of this form of idiocy, the action item isn't to call more reviews as the real challenge may be that they are simply called too late in the lifecycle in order to affect change.
It would seem to me that the Agile community actually has a better answer that needs a little extension. Ever heard of Extreme Programming? The notion of building test cases first before a line of functionality is borrowed from the engineering discipline. Before you build a bridge, you should have a clue as to how to test it for load and stress. The same thought process should apply for enterprise software.
Why should architects spend time drawing diagrams that is almost always guaranteed to be misinterpreted when instead they could use design-by-contract and ensure that all subsequent code is testable? What would happen if architects and not developers were responsible for writing/creating test cases? Do you think this could be a solution to removing the predictable deviation from as-designed vs as-built...
| | View blog reactionsAs an Agilist, I am savage in the pursuit of finding better ways of developing high quality working software. It seems to me that the notion of design reviews fail to acknowledge that there is a significant gap between the architecture diagrams produced by architects and the code written by developers. Even when people were co-located in the same building, their was a strong likelihood of misinterpretation and bad communication. This is only exacerbated when you put Indian IT outsourcing into the mix.
Can we possibly think that a few hours set aside for a review can solve miscommunications either due to the architect not describing their designs clear enough or the developer not being experienced enough to fill in some left-out detail that the architect considers obvious? Independent of this form of idiocy, the action item isn't to call more reviews as the real challenge may be that they are simply called too late in the lifecycle in order to affect change.
It would seem to me that the Agile community actually has a better answer that needs a little extension. Ever heard of Extreme Programming? The notion of building test cases first before a line of functionality is borrowed from the engineering discipline. Before you build a bridge, you should have a clue as to how to test it for load and stress. The same thought process should apply for enterprise software.
Why should architects spend time drawing diagrams that is almost always guaranteed to be misinterpreted when instead they could use design-by-contract and ensure that all subsequent code is testable? What would happen if architects and not developers were responsible for writing/creating test cases? Do you think this could be a solution to removing the predictable deviation from as-designed vs as-built...
