3 ms·

If you program in a bottom up fashion, you can test your code seamlessly while you write it. In Lisp for example, you simply check that the function you just w

by tsally 18y ago

If you program in a bottom up fashion, you can test your code seamlessly while you write it. In Lisp for example, you simply check that the function you just wrote returns what you expect. If not, you fix it right then and there. While I can't present any evidence to back up my claim, I imagine programming in this way reaps the same benefits of test-driven development without adding as much time.

Xixi 18y ago
The problem is not to write something that works, bottom-up, as you type it. Any half-decent software engineer can do that. The problem is maintenance : when you start to modify existing code, a function many other functions rely on (I assume functional style, without side-effects here). And sooner or later you'll have to alter your code, whatever the reason: spec change, performance issue, bug, new problem to tackle, you name it. The simplest thing I can think of is if you have to alter a function to handle correctly some corner cases. You didn't think about them when you wrote the function in the first place, so basically your function was buggy all along... Now you have to test all the functions that rely on this function again. What if they relied on said bug and you didn't realize it ? With tests, you just run the tests (and hope they were well designed...). With your technique, you do the same, by hand, function after function... Or to remain in a very bottom up style, what if you realize that one of your underlying brick was poorly designed ? It just doesn't address well the new problem at hand and need little enhancements... Anything that relied on this brick have to be, well, updated to use the new functions, and of course checked again. Again unit-tests come in handy... Note that I'm just making the case for unit-testing, not test-driven developement itself...

3 ms·

If you program in a bottom up fashion, you can test your code seamlessly while you write it. In Lisp for example, you simply check that the function you just w

by tsally 18y ago

Xixi 18y ago
The problem is not to write something that works, bottom-up, as you type it. Any half-decent software engineer can do that. The problem is maintenance : when you start to modify existing code, a function many other functions rely on (I assume functional style, without side-effects here). And sooner or later you'll have to alter your code, whatever the reason: spec change, performance issue, bug, new problem to tackle, you name it. The simplest thing I can think of is if you have to alter a function to handle correctly some corner cases. You didn't think about them when you wrote the function in the first place, so basically your function was buggy all along... Now you have to test all the functions that rely on this function again. What if they relied on said bug and you didn't realize it ? With tests, you just run the tests (and hope they were well designed...). With your technique, you do the same, by hand, function after function... Or to remain in a very bottom up style, what if you realize that one of your underlying brick was poorly designed ? It just doesn't address well the new problem at hand and need little enhancements... Anything that relied on this brick have to be, well, updated to use the new functions, and of course checked again. Again unit-tests come in handy... Note that I'm just making the case for unit-testing, not test-driven developement itself...