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 yo

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...