Geek Culture
Published in

Geek Culture

Technical debt

Own your technical debt

Why they won’t let you pay it

Photo by olieman.eth on Unsplash

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?

Photo by Towfiqu barbhuiya on Unsplash

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:

A Passion for Security: Intervening to Help Software Developers.” 43rd International Conference on Software Engineering (ICSE 2021)

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)


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.


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

Photo by Sebastian Herrmann on Unsplash

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!

Cheers! :-)

If you like this story, hit the clapping hands at the end so I know what you want to read about.

I don’t make a dime with the blog. If you want to support the creation of more content, share the blog with your coworkers and follow it to be notified of new stories!




A new tech publication by Start it up (

Recommended from Medium

Welcome the new Flux V2 on BSC and say goodbye to the old Flux V2 on Heco

C++ Pointers

My Journey Of Getting Started With The “” Course

How to optimize C and C++ code in 2018

The Misplaced Technical Interview

Programmatically Change Drawable Gradient in Android Studio

Programming Paradigms

Why I'm avoiding to call myself an agilist

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Peter P. Lupo

Peter P. Lupo

Many management blogs focus on soft skills. This blog is about hard skills! Measurement, indicators, approaches, etc., for Software Engineering Management.

More from Medium

Managing the software development team

We built a dual track engineering career ladder. Here’s why.

Why we care about tech debt

Why Test Runners Neither Test nor Run and What Software Developers Should Be Doing Instead

Female engineer controlling a simulator.