You Load 16 Tons and Whadya Get?

 

Maybe it's time to update our spell-checking service

Today I want to tackle that most fascinating of topics - Technical Debt.  It's a topic over which engineers will argue endlessly and never reach a consensus definition.  It's also a topic that management will acknowledge needs to be addressed, and then drop it indefinitely, even as the company's aging systems creak precariously along.

The good news is I'm here to provide a definition of technical debt and tell you the methods for solving it - no need to quibble with me, because I'm right!

Let's start with the definition of the term "Technical Debt".  This is where people often get pinned down, because technical debt, unlike monetary debt, is a poorly defined construct.  Since it's a poorly defined construct, it can't be effectively measured, and therefore can't be effectively addressed.

If you can't clearly define technical debt, it doesn't mean you can't make inroads to reduce it, but your improvements will either occur in the most obvious cases or will be a result of luck because you've picked one metric that just happens to correlate with a reduction of debt.

With that in mind, the best definition I've been able to compile to date is this one:

Technical Debt is the difference between a reasonable manager's or Product Lead's expected date of work completion and the amount of effort needed to complete that work.

What does this mean?  If your leadership is expecting a feature to be completed in 2 weeks and you tell them it'll be 6 months (I've witnessed this more than once), it's safe to say that you've got significant technical debt.

Let's dig a little bit more, though, to try and head off some of the more specious arguments.  I added the 'reasonable' prelude to the expectation, because, let's face it, there's always some jack-ass willing to burn your time in order to burnish his career, and his estimates aren't reasonable.

Reasonable means that both engineers and leadership are using a common vocabulary to discuss the effort and that an engineer can explain why the timeline can't be met while working standard 40-hour work weeks to accomplish the goal in the time allotted.

When faced with this type of sticker shock, it's imperative to continue the conversation.  Sometimes the engineers are over-thinking the scope or the debt incurred isn't a major factor at this point.  It's also possible that they're correct, there are shortcuts to be had that will increase the debt further, but the feature is so important that borrowing even more in the short-term is more important.

Often, this last point is what businesses do with a cavalier attitude of we'll fix it later, but then let the interest payments lapse.  By enumerating the gap, you can still do that, but it's harder to hide and becomes a more important part of the overall prioritization conversation.

Also, in creating this definition, it begins to surface means to tackle technical debt.  In the past, I've seen teams attempt to tackle debt by begging for a separate project to handle debt-laden services.  I've never seen the request approved, except in the case of a platform rewrite, which is a completely different animal in which an entire organization suffers a mass delusion that somehow blowing up working software and starting from scratch is better than incremental change.

Yes, we know Rome isn't perfect, so we've decided to reduce everything to rubble, level the seven hills, and start over.  Latin is also tedious, so we've decided to use Esperanto as our base language.  Isn't that better?

Outside of said delusion, no manager or Product Lead is going to sign off on a technical debt project that lacks a solid ROI number around the effort when there are features to be shipped and further debt to kick down the road for people to address after the current regime leaves.

The other tactic teams employ is carving out a Technical Debt Day.  If they have sufficient support from a manager, that may even occur on a weekly or monthly basis.  But, because the effort lacks a clear objective, it proves difficult to make any progress.

First, these efforts are often centered around code refactoring (changing the code to be easier to read and write for those unfamiliar with the terminology) which is often a necessary part of paying down tech debt, but, when applied in these situations, becomes a particular developer's assault on their favorite digital windmill.

Occasionally, this works out, but often it's someone's puritanical approach to rewrite code in the manner they see most fit.  I've said it before, but it bears repeating - everyone hates everyone else's code (as well as iterations of their own previous code).  There are almost no circumstances in which people will look at a system-in-the-large and agree that it was well composed.  It's either too flexible, too rigid, uses unusual conventions, or prefers tabs over spaces.  

To reiterate, refactoring is a necessary part of reclaiming tech debt, but engineers need to realize that code, much like this beautiful blue and green orb on which it exists, is imperfect.  Can using tabs instead of spaces screw with your code editor formatting?  Sure, but you can live with it.  It isn't a reason to make broad changes.

The second problem with a Tech Debt Day is that tech debt is tech debt because it has become monumental enough that it requires a concerted effort to address.  Trying to address it one day out of a week that is as equally likely as any other to be beset by interruptions doesn't pay the debt down very fast.  In fact, it may even increase tech debt if the project is left dangling for too long or Tech Debt Days are abandoned.

If you can't ask for permission to address tech debt-in-the-large and you can't work on it piecemeal, what can you do?  Well.  Lie.

I'm half kidding.  The sanest way to pay down debt is to address it as part of a larger project.  If you're adding a new feature that's relying on some ancient version of an API that you can work around but is going to cause you significant grief, this is the perfect time to address the issue.  

Most managers and Product Leads either don't have the time or the ability to micromanage the entire estimate process, so adding time to the overall estimate to handle some of the debt is likely to go unnoticed.

Of course, that's assuming you're envisioning and estimating your tech debt work in the same fashion you are the feature work and that the estimates don't completely blindside your leadership.  As a rule of thumb, I'd say that padding your estimates by 25% gives you sufficient leeway to cover the additional work without drawing too many grumbles.

Ideally, you should be able to tell your leadership that you're doing this work, but if your Product Lead (because it's almost always Product and not Tech management) is a deadline hawk, then just lie.  Technical debt issues need to be addressed and you can always remind Product that you're doing it for them anyway, so their eyes don't bulge when your estimates don't match their expectations.

The other possibility, depending on the composition of your team, is to assign someone to a shadow project.  This typically worked for me when I was running infrastructure teams, because management doesn't know what infrastructure does or assumes they're working support tickets all day, every day, and, therefore, doesn't bother to account for the engineers' time.  

If this is the case, then it's a possibility to have one or more engineers carve out time to address long-standing problems.  Due to the nature of the work, it's usually more senior engineers who are well-suited to the efforts, because of the scope and the perceived tediousness of the work, which could demoralize junior staff.

If you're concerned by this deception or think it's a misappropriation of corporate funds, I guess that's a viewpoint, but not one that's constructive or that addresses the realities of the situation.  I would prefer that teams have open conversations with management about technical debt loads, but management, historically, is incapable of understanding the complexities and the associated threat and, thus, extremely unlikely to prioritize work that's critical to the business even if they can't grasp the reality.

And that's how to conquer technical debt.

Until next time, my human and robot friends.