When I was in college, learning the art of programming through Pascal, we were told to be ‘lazy’ (not a hard sell I can assure) - to always put off the detailed work till last. In otherwords, we were to code the high-level abstractions first, and then pass-by-pass, work our way down until we were able to write the building-blocks of a program’s logic - the functions that did the simple but fundamental operations. The idea was to break the big problem down into smaller problems until we got to a point where the problem could be expressed in terms of operations that even a stupid computer could understand. This was a great education, and a philosophy that can be applied to many of life’s complex problems (divide and conquer!). But I’m not sure anymore that it’s the right way to build software solutions.
The problem with this breadth-first approach is that by the time you get to coding the lowest levels, you find some unexpected complexties that force you to change the assuptions that led you there in the first place. Those broken assumptions tend to lead directly to broken interfaces and a need for design change, but the effect of these changes are felt over the code that you have completed. Put another way, you cannot be sure of your emerging design until you deepen it to its logical conclusion. If you do that in a breadth-first way then you’re just making more code to fix.
What’s at issue here is that even if you are code-centric, and designing using up-front code instead of up-front UML, it’s still easy to fall into a breadth-first design approach. This all points in one direction: Test-Driven Development.
TDD forces you to drill down on a class’s deep implementation as quickly as you can, maintaining only minimal contact with cooperating classes on the way down. These cooperating classes are only identified through interfaces, and mocked off. At the end of a TDD session, when the class being developed is passing all its unit tests (and therefore that part of the design has been quite robustly validated), the by-product will be evolved interfaces to any required cooperating classes. I say ‘evolved’ because they will have mutated from when they were first identified earlier on in the TDD session, to when the session is complete. They will have suffered the inevitable design change up front, and before there is any implementation behind the interface! Much cheaper, much less painful.
Depth-first development is a better theoretical fit than my Pascal programming lecturer taught me. And Test Driven Development is a practical application of that theory.
TDD is not yet mainstream but it is standing up to scrutiny and use by a lot of ‘celebrity programmers’ (Adrian Colyer described it as “the best thing I have done for my development” when he spoke recently here in Cork) as well as a horde of hidden humble hackers like myself. I think, I hope, that TDD will become as accepted as the unit test technology that unterpins it.
- brendan lawlor -
Technorati Tags: Test-Driven Development, TDD, Adrian Colyer, unit test
0 Responses to “Depth-First Development”