Refactoring is Like Exercise


Refactoring, they say, is vital to maintaining a healthy code base. We all know we should do it, but many of us don’t.

Exercise, they say, is vital to living a long and healthy life. We all know we’ve got to do it, but many of us don’t. Maybe we dabble from time to time, or make a point to at least go play basketball in the park on one Saturday a month, but the real value of exercise comes from doing it regularly and for the entirety of your life.

Refactoring — improving the internal structure of code without changing its behavior — they say, is vital to maintaining a healthy code base. We all know we should do it, but many of us don’t. Maybe we excuse it because we’re continually pressed to get things done faster, or because we don’t really want to, but the real value of refactoring comes from doing it regularly for the duration of the code’s service life.

Both are Vital for Health

As we mentioned in the introduction, both refactoring and exercise are vital for the long-term health of the thing on which they work. We all know we should do both, and some of us do regularly. But more of us instead feel shame and guilt about how and when we don’t do them.

Feelings of guilt and shame show us that we know we should be doing these things. That the consensus of experts clearly and affirmatively speaks to their importance. But they’re hard and require real regular work, so aren’t always done as much as they should be.

Both exercise and refactoring are simultaneously indulgences and essential, necessary and easy to skip. They are things that aren’t materially obvious, and yet they’re things that make a big big difference if skipped for a long time. As someone who spent a number of years getting winded when climbing a few floors of stairs, I know that’s true of exercise. And as someone who has effectively been forced to cease all forward progress on developing an application for lack of refactoring, I know that’s true for code too.

Neither is Easy to Casually Observe

Both refactoring and exercise aren’t seen by outsiders, except for when actively observed, so it is easy for others to miss that you’re doing it in either a positive or negative way.

What we’re driving at is a vital point: to most outsiders most of the time, both exercise and refactoring work is invisible and has no obvious impact. It is possible — I know from experience — to be a regular exerciser and still have some substantial paunch. It’s also possible — though I’ve never had the experience — to be a rail-thin non-exerciser.

Because both refactoring and exercise aren’t seen by outsiders, except for when actively observed (say by driving past you running or reviewing your commit logs), it is easy for others to miss that you’re doing it in either a positive or negative way. The fact that refactoring (and the architecture and a software system) is basically invisible means non-coding managers have a tendency to skip it. Because exercising is easy to miss, it’s easy for you or the people in your life to make it one of the first time expenses to go.

Both Make You Better Able to Move Fast

But while they’re invisible, both exercise and refactoring give some highly valuable things. For exercise, this is either strength — from lifting weights, etc — or the ability to move faster — from running, biking, etc. Almost all exercise gives you an increased stamina, adaptability, and ability to accomplish physical tasks fast. It allows you to take all your groceries in one massive armload, or in a lot of very very quick trips.

Refactoring, when exercised regularly and with wisdom, makes it so much easier to add new feature to an application, or find easy performance wins. Because refactoring has the basic effect of making a codebase more coherent and concise, these things just come along for the ride.

Neither is Pleasant 100% of the Time

One of the most valuable things to refactor is that few-hundred-line monolithic function that scares you and the rest of your team.

With both refactoring and exercise, it’s also possible to do it wrong and not realize the benefits. Run wrong for too long, and you’ll do some serious injury to feet, knees, hips or all of the above. Do your refactorings sloppily and you can easily end up with newly-broken features. But in both cases, that’s just what happens if done wrong.

More than the risk of doing it wrong, there’s also some short-term pain that is truly vital to the activity. Even with proper form, lifting a new personal best weight, or running a new personal best 5K require that you push and strain a little more than you would otherwise. This effort, this pushing past the point of comfort, is a vital part of getting better at any physical activity. And, of course, you must not overdo this pain. That way, injury lies.

So too, with refactoring. One of the most valuable things to refactor is that few-hundred-line monolithic function that scares you and the rest of your team. It is precisely where refactoring is scariest that you realize the greatest rewards. But that small short-term pain is vital. And, as with exercise, some humility around risk is needed to prevent frustration or bodily harm.

Doing it Regularly is Important

The takeaway here: both refactoring and exercise are good things to do, great even. Both measurably improve your sense of capability and your ability to move fast. Your overall health and ability to pivot is strengthened by doing them. If you push through the necessary pain of both activities, you’ll end up with a vitally important set of improvements. If no one else notices all the effort, that shouldn’t stop you: both are valuable and necessary nonetheless. And if you can learn to enjoy them, both pay huge dividends over the course of your life.

Image Credits: ryanknapp

About David Hayes

David likes learning, solving hard problems, and teaching. He bikes a lot, and lives in (and loves) Colorado. You can find him on Twitter as @davidbhayes and check out his latest hobby-project, Quodid, a monument to his love for pithy bits of wisdom.

Leave a Reply

Your email address will not be published.