Pay Down Your Technical Debt Faster by Limiting Your Payments

Paradoxically, employees who want to take vacation and/or clean up their code do less of it when they have “unlimited” time

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

“Technical debt” is a pseudo-financial phrase coined by Ward Cunningham. It describes the idea that you can ship crap code faster than you can ship better code, but it’ll be harder to improve upon the bad code.

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

As engineers, we all find ourselves working on legacy code from time to time, and we feel that our productivity suffers as a result. If only the managers would give us more time to refactor, to rewrite, to clean up.

But it can be difficult or even impossible to convince the organization to work on technical debt—to take extra time to get the code “right,” reducing the “principal” of debt rather than increasing it—because the costs of technical debt can’t be quantified.

Interest payments on technical debt impact the productivity of software engineers who work on legacy code, but, infamously, the productivity of software engineers cannot be measured. Some of the minutes spent working on not-quite-right code were wasted, but we don’t know how many minutes were actually wasted, because we can’t know how long it was “supposed” to take you to fix the login page (again).

Instead of measuring productivity, we’re forced to measure employee satisfaction. Technical debt can’t be measured in mythical man-months. It can only be measured in tears, as engineers weep in frustration over code that they desperately want to refactor.

Technical debt can only be measured in tears

It turns out that paying down the principal of our technical debt (taking extra time to get the code right) has a lot in common with taking vacation, including a paradoxical result: when managers offer employees “unlimited vacation,” the employees take less vacation than they do when they can accrue vacation hours with a hard limit (a cap). Similarly, engineers spend more time paying down technical debt when it’s structured like limited vacation than they do when offered “unlimited” time to work on technical debt.

Unlimited vacation results in less vacation

From time to time, firms have experimented with offering “unlimited” paid vacation. What they often find is that employees take less vacation as a result. For example, in 2015, Kickstarter ended its unlimited vacation policy for that very reason.

Partly that’s because, regardless of what they say, managers have expectations for how much output they expect their employees to deliver. When managers establish a formal vacation policy, they’re setting those expectations in writing. Without a formal vacation policy, when a manager says, “Take all the time you need,” employees have to infer how much time the manager expects them to take off, based on the behavior of other employees and other subtle non-verbal cues like how hard the manager’s face puckers when saying, “Take all the time you need.”

It’s also because employees in US firms already struggle to use their allocated paid time off, even when they’ve earned it. The US Travel Association’s Project: Time Off reported that Americans use only 77% of the PTO that they earn each year, in some cases giving up days or even weeks of paid vacation under “use it or lose it” policies.

Everybody and their boss know that taking vacations is important for your health as a human being, and for your productivity at work. But just because vacation is important doesn’t mean that it’s urgent.

Do I really need to take a vacation right now? We’re under deadline, after all! (If we’re managing the organization efficiently, we’re literally always under a deadline.)

Establishing “use it or lose it” caps can give vacation urgency. It gives employees the license to say to their teams, “I’m sorry, I know we’re all struggling to fix our P1 bugs before Put a Pillow on Your Fridge Day, but I just have to take my vacation by the end of the month or I’ll lose it!”

Fans of unlimited vacations will point out that you can get a similar effect by saying, “Everybody has to take at least two weeks of vacation every year,” but mandatory-minimum policies tend to encourage employees to take barely the minimum amount of vacation. What’s the point of unlimited vacation if everybody just takes the minimum?

Establish a technical debt budget for each engineer, to make sure they actually spend it

Just like vacation, it can be really difficult to justify to the organization that we should pay down technical debt right now. After all, the purpose of your business is to satisfy your customers, not to satisfy your employees. (If you’re a worker-owned syndicate, maybe the purpose of your organization is to satisfy your shareholder-employees, in which case your employee satisfaction budget should be as large as you can afford.)

But it turns out that it’s actually pretty easy to justify some expenditures of time and money to improve job satisfaction. Every business needs a budget to maintain employee morale. That budget can be spent on improving benefits, vacations, nap pods, alcohol, designer coffee, king-size Butterfingers, or whatever. If it turns out that working on a giant ball-of-mud PHP file is making you and your team unhappy at work, and especially if your unhappiness is our only measure of your productivity, it makes sense to budget for refactoring.

So how big should each engineer’s technical debt budget be? Let’s pick a number. Perhaps we might allow engineers to spend 20% of their time on improving their own productivity. “20% time” is Google’s famous policy to allow their engineers to spend 20% of their time on self-chosen projects. A lot of Googlers have used it to pay down technical debt.

But if you talk to Googlers about 20% time, you’ll find that many of them report that they never really get to spend it. People call it “120% time.” “Do a full work week, and then on Saturday you can work on anything you want!”

20% time without a cap is like accruing vacation hours without a cap. Both are important benefits for the employee, but never urgent. Employees never have the social excuse to say, “I have to work on this 20% project today,” or even “this month.”

A refactoring budget can keep your yak warm, too

Hooray, refactoring day has finally arrived! I finally get to redesign that crufty old build script that has bedeviled me all year! Oh, but wait, it’s connected to these five other pieces of code. And it’s used in twelve other places I didn’t even realize.

Like every software project, refactoring projects are difficult to estimate; paying down technical debt can easily spiral out of control. In fact, if you’re a professional software developer, I bet it’s already happened to you accidentally. “While I’m in here,” you think, “I’ll need to clean up this one bit of code,” and hours or even days later you can barely remember what it was you were working on in the first place.

We programmers have a name for this feeling, the feeling when yanking off one loose thread requires unraveling an entire sweater and reknitting it out of yak hair. We call it “yak shaving.” According to the classic Jargon File, yak shaving is “any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you’re working on.”

A warm, unshaven yak. image credit: wikipedia

This “yak shaving” problem is another big part of the reason why engineers and managers disagree about how much time we should use to pay down technical debt.

Wait, you want two weeks to work on technical debt that can’t be measured, resulting in productivity gains that can’t be measured, and you can’t even be sure that you’ll be done in two weeks?!

But when engineers have a refactoring budget, they’re empowered to make good choices about how to use their refactoring time. If it turns out that big rewrite of the booger classification system will take four weeks instead of two, maybe I’ll do part of it now and part of it later, or maybe I’ll stop working on it now and save up more time to work on it in the future. Maybe I’ll use my budget on other smaller refactoring projects instead.

As software engineers, we often rail against arbitrary, capricious bureaucracy. Why does our JIRA template have so many required fields? Why do I have to email a spreadsheet to file my expense reports? Why do I have to jump through hoops just to add a new dependency on an open-source project? Sometimes, we need to just get rid of the rules, but sometimes, questions like these have surprisingly good answers; not all good rules are good for obvious reasons.

Vacation caps, it turns out, are a surprisingly good idea. I recommend establishing formal limits on refactoring, too.

Discussion on Hacker News

Discussion on Reddit

P.S. Redfin is hiring.