So I have always thought that BDUF was flawed. I never enjoyed it, something just felt wrong. Over the last year I have been participating in agile experimentation at my work. For most new features we would have to document a design (UML and text) and hold a design review before proceeding to create unit tests. What was the purpose of these design reviews? To make sure that the implementor was going to express the values held by the architect in the code. It’s not that the developer was not trusted to fulfill the requirement, they were not trusted to hold and express the values of the architect (In this case the values are of OOP). So this indicates to me that the design documentation and review are to direct the implementor as to how they will fulfill the requirement.
I was very attached to this project and its success. I would monitor the CCNET server and review most every change made to the product. When I saw that the design was going astray I would talk with the author of the disruptive change to see what could be done to right the design. In monitoring the product in this fashion I found that design documentation and review were rarely translated into the expected code. This says to me that no amount of direction can get a developer that does not understand and or hold the desired values to produce code that adheres to them.
So I am sure you are asking how does this relate to Continuous Design. Well I don’t have a solution to how to get good code out of developers in opposition to the desired values. It feels like to me that Continuous Design has something to offer here. You might be saying use pair programming. Well that just seems like one developer (the one with the understanding) is doing all the work and the other developer (the one lacking understanding) is getting trained (if they are open to it). That doesn’t really sound like pair programming to me (maybe I don’t understand pair programming well?). At any rate I like Continuous Design better that BDUF. I think it is more productive. It reminds me of the Ron Jeffries quote:
“If I’ve got six months to build a system, then I’ll spend six months building it. I’ll also spend six months designing it, and another six months testing it. The good news is that it’s the same six months”.