Own your technical debt

Technical Debt

Ward Cunningham first mentioned the technical debt (TD) metaphor in 1992 [Cunningham, 1992]. His definition, “not-quite-right code,” remains the most commonly cited. Still, it has been extended to refer to those internal software development tasks chosen to be delayed, but that run a risk of causing future problems if not done eventually. Thus, it describes the debt that the development team incurs when it opts for an easy or quick approach to implement in the short term, but with a greater possibility of a negative long-term impact.

Debt can refer to any aspect of the software that we know is inappropriate but do not have time to fix at the moment, such as outdated/missing documentation, planned testing that is not executed, overly complex code that needs to be restructured or refactored, and known defects that remain uncorrected. These immature artifacts result in unexpected delays in carrying out necessary modifications and difficulties meeting the project’s established quality criteria [Spínola et al., 2013] [Zazworka et al., 2013].

Why do you accumulate TD?

As software engineers, were not asked to do half-baked stuff. We are asked to do things that work properly. Often, when business and product areas ask us to compromise, they are ok with reducing the scope to fit the budget or schedule before we compromise on quality.

This means that a priori, there is no reason to acquire TD. Most of the TD acquisition I’ve seen in my career was perfectly avoidable. It was acquired because it was the easiest option on the table.

Unfortunately, it’s easy to choose this option because the negative consequences are not understood by non-enginers. That sounds obvious, but it’s not. By giving this option you are basically asking other people to decide for you over 2 major issues you are accountable for. More about them in the next section.

Before I talk about them, let me share with you a 2:30 minutes video. It’s a cut from a presentation of a brilliant paper that talks a great deal about security technical debt:

In essence, they don’t have the mental model to understand the dangers of TD accumulation to the organization, because it is not their responsibility to do so. So…

Don’t ask others for authorization to do what is part of your job.

As engineers, we are accountable (among other things) for quality and productivity.

Engineering Accountability (part of it)

Quality

Accumulation of TD often causes regression issues. You change one thing that is highly coupled to another when it shouldn’t be and this other one breaks. Or you make a change expecting a certain result but you get unexpected results because you can’t understand the code.

Productivity

Stakeholders will expect that your team’s productivity stays constant (if not improve). And they will, at some point, complain about delays and things taking time to be completed or resolved.

Accumulation of TD goes against that and will hinder your team’s performance. I’ve seen that happening first hand. That’s right, I’ve seen a team completely halting production related to a specific component because there was no way to guarantee it would work after more changes, results of 20 years of accumulated TD.

As engineers, we are accountable for quality and productivity. Even more, if you are an engineering manager, like me.

So, reserve the effort necessary to get productivity and quality to the level that is expected and keep it at least stable. The remaining effort can be directed to production. Once it’s stable at the level that is demanded from the team, you can allocate more effort to production.

In other words, every time you offer to acquire technical debt you are, in practical terms, failing your responsibilities to the organization as an engineer.

How and when to compromise

Of course, I recognize there might be lose-lose situations and business must do what it has to do to thrive. That means you will have to concede to business deadlines.

The good news is that deadlines pass, so when you face this situation you must be ready to get an agreement with business and product areas that this debt must be paid because it interferes with your team’s ability to do their job.

But if you already have TD and want to start paying it, check this other post!

How much technical debt do you own? - Identify and catalog your technical debt

Cheers! :-)

If you like this post, please share it (you can use the buttons in the end of this post). It will help me a lot and keep me motivated to write more. Also, subscribe to get notified of new posts when they come out.