Top-down and test-driven development
I've been always advocating top-down approach to software development. This was based on my experience. Bottom-up leads to impedance mismatch problems; top-down creates clean architecture. I know I'm right, but how do I convince others?
And whenever I do a code review I have to be convincing. Just saying, "Trust me, I've done it a million times" doesn't always work.
What got me thinking about it is the test-driven methodology. It's a gimmick, which is useful in some specific situation, and is touted by some extreme programmers as panacea for all programming ills. The main point of test-driven development is that you first design a set of tests and then develop a component that passes them. At every step you use minimalist approach--you don't design for generality, you just want your component to pass the next test. The advantage of this approach is that you end up with a component that is built exactly to the spec--the spec being defined in terms of your tests--no more no less.
Of course, the problem is now shifted to designing appropriate tests--not an easy task! These tests create an environment for your component. The component evolves to fit this environment. Conceptually speaking, to design a plane, you first build a wind tunnel. If the plane passes all tests, it will be able to fly in your wind tunnel--which, incidentally, is not the same as flying in the airspace.
So the main question is, how well does your test suit simulate the actual environment where your component will live?
Now, going back to top-down approach--when you build your software top-down, you are, at each step, creating the actual environment in which your component will live. This reasoning clearly shows both the advantages and the shortcomings of top-down.
The main advantage is that the component is built to the exact specifications of its environment--you'll know what data, and in what form, will feed your component. You'll know what output is expected from your component. You'll know its lifetime--creation and destruction time.
On the other hand, it might be difficult to re-create all testing scenarios in a live project. Testing special cases and boundary conditions might be hard.
But the main problem is when your component must serve in multiple environments. Here, from the very start, you have to abstract the environment for your component. This abstraction might be easier to describe by a test suite than by anything else.
Which brings me to the conclusion that test-driven development is best when you are designing for reuse.
Which is actually rare.
And whenever I do a code review I have to be convincing. Just saying, "Trust me, I've done it a million times" doesn't always work.
What got me thinking about it is the test-driven methodology. It's a gimmick, which is useful in some specific situation, and is touted by some extreme programmers as panacea for all programming ills. The main point of test-driven development is that you first design a set of tests and then develop a component that passes them. At every step you use minimalist approach--you don't design for generality, you just want your component to pass the next test. The advantage of this approach is that you end up with a component that is built exactly to the spec--the spec being defined in terms of your tests--no more no less.
Of course, the problem is now shifted to designing appropriate tests--not an easy task! These tests create an environment for your component. The component evolves to fit this environment. Conceptually speaking, to design a plane, you first build a wind tunnel. If the plane passes all tests, it will be able to fly in your wind tunnel--which, incidentally, is not the same as flying in the airspace.
So the main question is, how well does your test suit simulate the actual environment where your component will live?
Now, going back to top-down approach--when you build your software top-down, you are, at each step, creating the actual environment in which your component will live. This reasoning clearly shows both the advantages and the shortcomings of top-down.
The main advantage is that the component is built to the exact specifications of its environment--you'll know what data, and in what form, will feed your component. You'll know what output is expected from your component. You'll know its lifetime--creation and destruction time.
On the other hand, it might be difficult to re-create all testing scenarios in a live project. Testing special cases and boundary conditions might be hard.
But the main problem is when your component must serve in multiple environments. Here, from the very start, you have to abstract the environment for your component. This abstraction might be easier to describe by a test suite than by anything else.
Which brings me to the conclusion that test-driven development is best when you are designing for reuse.
Which is actually rare.