In a recent essay by Kent Beck, he details two contradicting methods for introducing change in software:
1) Make it run, make it right, make it fast.
2) Make the change easy, then make the easy change.
The former is generally how we are taught to execute TDD – do the simplest (even stupid) thing to get the test green, then re-factor with your safety net in place.
As systems grow, the second technique becomes useful. When you can’t grok all the code in front of you, work to break it down until you can attack the problem at hand.
The key element of these two techniques is to suspend thinking about the end goal and make ourselves temporarily uncomfortable to simplify the problem domain. Either technique creates the momentum one needs to get to a solution, rather than ending up in “analysis paralysis” or thrashing between several contradictory goals.
As someone with legacy code experience, I usually reach for the second technique before the first, and have often felt guilty about it. First, when carrying out an extensive re-factoring, there can be a long time where I fumble through the change. That’s time where I’m not “adding business value” and “getting things done”. Additionally, I’m abandoning my trusted feedback loop of TDD. The tests will continue to pass (I’m re-factoring safely), but I don’t know that this “make it easy” step is actually leading me in the direction I need to go. At this point in my career, I’ve performed several hundred pointless re-factorings that didn’t end in the desired result or advance my knowledge of the system in a meaningful way.
In some cases, it’s a bad idea to “make it easy” first. In others, there’s so much technical debt standing in the way, that “make it run” is at best a terrible, fragile hack. And once it runs, it’s pretty tempting to mark it as done and pick up the next card, rather than taking the 3 weeks it will likely take to “make it right”.
I like the tone that Kent sets, where there is a time and place for each technique. Thinking tactically, “make it run, make it right” is the safe decision. Of the two methods, only the first has any value if it’s 50% complete. I’d caution anyone considering “making it easy” to be wary of the time that might take and set appropriate timeboxes. Technical Debt will eventually need to be paid down to make progress, but today might not be that day. Of course, like any decision for short-term gain, it could be pretty painful if you don’t follow through and “make it right” before moving on.