Let’s Talk About Technical Debt: What Are We Really Talking About?

We're zeroing in on technical debt because according to our Kotlin developer survey, 25% of Kotlin developers are wrestling with technical debt on an ongoing basis- in fact, they say it's their biggest challenge in 2024. 

So it would appear that it really isn't just another buzzword—it's a significant concern that's impacting the way many in our community work. So let's break down what we mean by technical debt and why it's capturing so much attention from Kotlin devs.

What is Technical Debt?

Simply put, technical debt is a concept in software development that describes the implied cost of additional rework caused by choosing an easy (or quick) solution now instead of using a better approach that would take longer. Originally coined by Ward Cunningham, the term highlights the compromises developers make under various pressures, leading to long-term consequences that may hinder software performance and scalability. One of the authors of the Agile Manifesto,  Ward Cunningham said that that some problems with code are like financial debt. It's ok to borrow against the future, as long as you pay it off.

Martin Fowler’s Technical Debt Quadrant

Ever heard of Martin Fowler’s Technical Debt Quadrant? Martin Fowler is a renowned software engineer and author, best known for his influential work on software development methodologies, refactoring, and software architecture design as the Chief Scientist at ThoughtWorks.

His technical debt quadrant is pretty insightful and shifts the focus from simply labeling something as technical debt to understanding the nature of the debt. Fowler introduces a handy framework to classify tech debt, not just as good or bad, but with a bit more nuance. It's divided into four quadrants based on two axes: Reckless vs. Prudent and Deliberate vs. Inadvertent:

Here’s a breakdown of what each quadrant represents:

1. Reckless and Deliberate: This is technical debt that’s incurred when a team intentionally skips necessary steps like design due to time constraints or other pressures. The common mindset here is “We don’t have time for design,” indicating a conscious decision to ignore best practices for immediate convenience.

2. Prudent and Deliberate: This quadrant represents a more strategic approach to technical debt. It’s when a team decides to accept debt knowingly, with the intention of addressing it later. For example, the team might say, “We must ship now and deal with the consequences later,” acknowledging the debt but also the need for rapid delivery.

3. Reckless and Inadvertent: Here, the debt occurs through ignorance or a lack of understanding. A team may not be aware of best practices or may lack experience. They might ask, “What’s layering??” indicating they’re not even aware that they’re making decisions that could lead to technical debt.

4. Prudent and Inadvertent: In this case, technical debt is accumulated unintentionally, despite the team’s efforts to make the best decisions with the information they had at the time. Later, they realize there was a better way to do things.

Fowler’s quadrant helps us to see that not all technical debt is bad or a result of poor decision-making. Some debts are taken on deliberately to achieve short-term goals, with a plan to address them in the long term, while others might be the result of unforeseen circumstances or lack of knowledge. Understanding this helps teams to manage technical debt more effectively and to communicate about it more clearly.

Navigating Technical Debt Communication Between Tech Leads and Executives

The dialogue between engineers and executives can often be fraught with, what should we call it - tension. Yes, tension. Engineers will usually be working to maintain technical excellence, while executives may be more focused on meeting business objectives quickly- rightfully so, as it's their job. There may be a culture or perception within companies that views time spent on architecture as less valuable or productive than time spent on developing new features. This can make it difficult for tech leads to advocate for the necessary focus on architecture.

And it's usually in this gap where technical debt will thrive. Basically, the root causes are deeply intertwined with organizational culture, communication breakdowns, and you guessed it, conflicting priorities.

So, how to skin this beast? Well, it starts with building bridges between tech teams and execs.

Picture this: cross-functional teams where everyone—from engineers to product managers to execs—works together toward a common goal. By breaking down silos and fostering open dialogue, we can start to ensure that technical decisions align with business objectives.

Execs, trust your engineering wizards to make informed choices, and engineers, don't shy away from sharing your insights with the higher-ups- even using some business lingo like ROI😉 .

Together, we can steer clear of technical debt pitfalls and pave the way for smoother sailing ahead.