I heard once that debugging and fixing defects amounts to half the cost of software development 1. Half of the time you spend writing code, you’re not actually writing code, your fixing code. It seems to me that a strong majority of the software development tools we have are devoted to this effort. Yeah, text editors are for writing code, but all the little tools like debuggers, print statements, and inspect element, are designed for fixing code. They are designed for decreasing the time spent fixing defects.
But what if instead of putting so much energy into decreasing this half of the process, what if instead we tried to decrease the amount of time spent writing code?
I propose a new software development methodology dubbed debug-driven development (DDD). By using test driven development, we can redefine the develop-debug process to completely eliminate the development step. Instead of developing a feature, we can fix a broken test and in doing so the development portion of the develop-debug process disappears.
Does that make sense? I think so. We can reframe a desired feature to just be a bug in the code, thus no development necessary, only fixing. We have now changed the entire software development life-cycle to have zero development. Besides cutting the workload in half by following DDD, you will also gain all the benefits of using TDD!
Writing tests first improve code on a number of different fronts. None of these benefits are only realized through TDD. The real benefit comes not exactly from writing the tests, but from always thinking about
how would i test this. It requires you to think first and foremost about what the program should do, not how it gets it done. This generally yields more intuitive interfaces that are transparent. Having all the tests in place once you’re done of course increases maintainability and reliability.
1 Reworking defects in requirements, design, and code consumes 40-50% of the total cost of software development. (Boehm, Barry W. 1987. “Improving Software Productivity.” IEEE Computer, September: 43-57.; Jones, Capers, ed. 1986. Tutorial: Programming Productivity: Issues for the Eighties, 2nd ed. Los Angeles: IEEE Computer Society Press.) ↩