Making It Right, Making It Easy


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.

2 thoughts on “Making It Right, Making It Easy”

  1. Dave Nicolette

    There seems to be an implicit assumption that the most important thing is to focus on value-add activity, almost to the exclusion of everything else. Steve has “felt guilty” about “not adding business value and getting things done.”

    IMO we need to strike a balance between tactical delivery and sustainable delivery capacity. As lean concepts have become more familiar to software developers, we’ve had a tendency to misinterpret the lean concept of muda. We can’t (and don’t want to) eliminate all muda. We have to maintain our capacity to deliver even as we drive value-add work through the process. Some overhead is required to do that.

    We’re going to have buffers in between value-add steps; we’re going to have some level of WIP (probably greater than 1); we’re going to have to do some code clean-up along the way. It’s not practical to spend 100% of our time on direct value-add activities. When we try to do so, we impede flow, which will almost certainly result in even higher costs.

    The refactoring you’re doing today is nothing more than the price of the hasty coding someone else did yesterday. Someone else already incurred that debt. Now it’s time to pay it back. You’re just the debt collector. Don’t feel guilty. You’re doing the right thing.

Leave a Reply