How This Technique Helps
Did you notice how the slowly growing test made it easy for me to make structural changes? I could make those changes with near impunity because the test would tell me if anything was broken. Thus, I was able to try a new structure as an experiment, and revert later if I didn't like the result.
And did you also notice that I made structural changes long before the whole module was complete? This meant that I had less code to change while getting the structure right.
Finally, did you notice that the variable and method names changed from structure to structure? I want my variable and method names to be as expressive as possible; so I try different names from time to time to see how they read.
Of course, all these changes are made much simpler by using a refactoring IDE like IntelliJ or Eclipse. In this case, I was using IntelliJ.
You may think that following these practices would take longer than just writing the code, as I did at first. But think of how much time you've spent wading through some "badly written" moduleperhaps one that you wrote a few months back. That is the time we're trying to save. By investing in the quality of the code now, we make it possible for that code to be maintained later.
Think of it this way. The fastest way to be done with dinner is to leave a mess in the kitchen. Every day, no matter how messy the kitchen is, you'll always be done with dinner sooner if you don't clean up the mess. On the other hand, dinner will take longer and longer to make, as you find yourself chiseling the dried crusty spaghetti from last week's plates.
Over a month, the way to spend the least amount of time preparing dinner is to keep the kitchen clean. Indeed, the best chefs clean up the kitchen while they prepare the meal.
Professionalism in software development is not simply about getting done quickly. It's about maintaining a level of quality that allows us to spend the least total time developing. To do that requires that we clean up the code while we're writing it.