Defect driven development
Copied from the original by Kirk Pepperdine.
Defect Driven Design Makes a Comeback
In 1996, a group that I was working with devised a development process which we called Defect Driven Design, otherwise known as D³. We were a bit disappointed by not surprised that D³ never really caught on but just recently I saw a glimmer of hope for a revival. It was quite a surprise when about a year ago when Cameron Prudy started telling me about this great methodology called Defect Driven Design. Geertjan Wielenga happened to be there and he immediately wanted to interview me for. So very early in the morning in a bar in Stockholm he filmed me while I explained D³. It was fantastic to believe that almost 15 years after it’s inception, it might happen. D³‘s time had come to be the industries true silver bullet.
Like most things in life, things that don’t make sense to developers often do make great sense to managers and the bean counters. This is clearly the case with D³. Let me explain by starting with a bean counters point of view before addressing why managers prefer this style of development.
D³ makes the most sense when you consider total cost of ownership though inception to product end of life. Of all the costs, maintenance is by far the largest. Unfortunately it is the cost that cannot be avoided. However we can avoid the costs of every other phase by simply eliminating them from the process. Costs of development? 0! Cost of requirement phase? 0! Cost of all the various forms of testing? 0! This is why bean counters love D³. The only phase that costs anything is maintenance but by eliminating the other phases, we have reduced total cost of ownership.
From the managers perspective, D³ makes most sense when you consider the painful task of scheduling. Lets face, trying to estimate when developers will finish any software project is like trying to predict Saturday’s evening lottery numbers. It’s like a stupidity tax. The dumber you are, the more you think you can do it, the bigger the tax you pay. So smart managers immediately get D³ because they recognize by getting rid of all of the phases, they’re going to be right far more often. How long does it take to collect requirements? No time at all! How about time to develop and deploy the application? Zero! Application is deployed immediately after the users request it. Testing? That rolls right into the maintenance phase. Users are happy, managers hit schedules.
So how is D³ able to provide all these benefits? This is best explained in terms of an example. Lets suppose a user comes up to your manager and says, “Scotty, we really need this mission critical application as soon as possible”. Instead of your manager saying, “our development team cannot take it, we can’t do anymore”, he can answer done!. If the user asks when it will be delivered the answer is, it’s been delivered!
Requirements collected in no time, delivery immediately taken care off . No need for long meetings with bean counters as you try to get funding to develop this application. That all melts away when you use D³. That said, it’s not quite the panacea that it’s been made out to be. The user will go to his desktop and look about for the application and not finding an icon will immediately cause him to report something like, “where’s the icon to start the application? I can’t find the icon.” This is the projects first defect, no Icon to start the application. No problem, generate that icon, fix the defect and report back that all is well. Second step, users clicks on icon and nothing happens. No problem, this is the second defect which will be reported and the maintenance programmers will work to get fixed. Third defect, fourth and so on.
By now you should see how D³ can solve the problems face by managers and bean counters. But, what about developers? I think we can all agree that the most tedious thing a developer is work on a brand new project. Having to go through design phases, making choice about which technology to use, how to get everything up and running. It can give one a headache just thinking about all of the technical challenges that come with starting a new project. However, with maintenance programming, all you have to do if look at the list of defects, pick one and fix it. Gone is all the tedium of trying to start a new project. No more headaches, long hours and loss of sleep trying to meet insane schedules set by your manager given impossible budgets by his bean counters. No more arguments about how we’ve got to rewrite this application from the ground up because it was poorly designed. Wit no design phase, there is no possibility of that phase producing a bad design. No messy code from the development phase to complain about. It’s really a win all round.
