I have heard of Responsibility-Driven Design (RDF), Test-Driven Design (TDD), and many other software design approaches. But here is a new one I discovered: Defect-Driven Design (DDD).
How does it work?
You start with a feature that sounds easy but is really complicated. Then you assign it to a programmer who has a record of succesfully doing the simpler type programs, but who is still very new to Test-Driven Development approaches. That way he will revert to his traditional code-only approaches (no automated testing, certainly not test-first). Be sure to pressure the programmer to get it done quickly, and give him complicated requirements. Make sure to assign his business analyst to several other projects so that he does not have time to give the programmer the quality guidance he requires.
Since the architecture is similar to other programs he has successfully written without test driven development, he proceeds to code the program with confidence that it will be as successful as the other programs. Once he has “completed” it, the testers test it, and start sending him the defects. He fixes them one at a time, thinking each time that he is “done.” Eventually, the testers discover a HUGE pile of defects. Then you realize “uh-oh. It was not really simple after all.” And all these test cases are the requirements that they never gave the programmer in the first place. (more…)