Image for post
Image for post

Technical Debt Isn’t Real

Or at the very least you should stop talking about it

David Vandegrift
May 29, 2019 · 6 min read

The origin of this nonsense

“Technical debt” was first used in 1992 by Ward Cunningham to justify an iterative, experiment-based approach to software development. His manager didn’t understand why the team was going to back to work on code that had already been written. Cunningham had to explain that the first code had been put out based on an immature understanding of the problem, allowing for testing and the development of a more mature understanding — which then had to replace the previous solution.

Why it’s bullshit

Of course, the original definition of a term doesn’t matter all that much in comparison to its real-world modern impact. And in the case of technical debt, that impact has been monstrously negative.

Image for post
Image for post
Visualization from the link above

When “technical debt” actually causes more debt

The biggest problem with the way the industry uses the term technical debt is that it actually hides a whole bunch of bad practices that are legitimately costing companies real time and money. Bad code is being written under the banner of “it’s okay to have some technical debt, we’ll come back and fix it up later”. Like Cunningham has been saying all this time, it’s never okay to write bad code.

When “technical debt” leads to bad investment

Of course, technical debt’s obfuscation doesn’t stop at covering up legitimate issues. It also leads to a monsoon of time and energy spent on fake problems.

When “technical debt” leads to bad culture

One of the things I’ve found with the “maybe” technical debt problems is that they’re not even universal perspectives on most teams. Maybe the senior engineer really likes comments before a function but several more junior members were taught to stick their comments after the function declaration. In most such situations, the senior engineer establishes “comments first” as a universal truth and any alternatives that sneak into the code base become technical debt. If those alternatives become prolific enough, the senior engineer may go so far as to declare a technical debt day in which a junior engineer is tasked with fixing all of the inconsistencies. All else equal, should the code have been consistent? Sure. But did the user give enough fucks to justify using an engineer’s day on it?

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

Thanks to Kathryne Dunlap

David Vandegrift

Written by

Founder/CTO @ 4Degrees, former venture capitalist, D&I advocate, lots of AI

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

David Vandegrift

Written by

Founder/CTO @ 4Degrees, former venture capitalist, D&I advocate, lots of AI

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

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