Imagine you are trying to cross a mountain stream. You could make a running leap and get to the other side. Sometimes that works, other times you get wet. When there are rocks sticking out of the rushing water, you can step from rock to rock and get across the stream without getting wet. Sure there are some streams you can jump across, go ahead and jump. Other streams require a more careful approach.

TDD is like the more careful approach, hopping from stone to stone. The diagram below represents the journey of two programmers, adding a new feature. The TDD approach means some effort is expended orthogonally to the ideal path, the straight line. Once on the other side you are done without the risk of being swept away by a mistake that leads to a long debugging session.

With Debug Later Programming (DLP) and Big Design Upfront (BDUF) you might feel like you are making better progress than the stone stepping test-driven developer. But if you end up in the churn associated with test and fix it could take a lot of effort, that you could not anticipate, to get done.

In the TDD steady state, each test moves the TDDers implementation closer to done. Often, there is a natural sequence to the tests, like the stones in mountain stream. Often there is more than one path. Sometimes you can get to a dead end, and have to back up and choose another series of stepping stones.

People doing TDD find the length of the line from start to finish is shorter with TDD. They also appreciate having the test safety net when changes eventually come.

TDDers and DLPers often end up at different places. The TDD design is refined as the journey continues, often ending up in a place not anticipated. The automated tests make refactoring a low risk activity,and an expected activity. The DLP design may have more issues as the risk of design improvements mean a lot of manual retest, and increased risk of new bugs.