A Quick and Complete Guide to Measuring Your Tech Debt and Using the Results

Rate this content
Bookmark

Hardly any people in Tech like when there's a lot of tech debt. And most of us would like when there's not too much of it. But how do we understand how much exactly we have of it? Where exactly does it sit? Which part of it is actually the most annoying? What would be the benefit for us if we spend time getting rid of it? When it comes to planning how you tackle your tech debt, all these questions deserve answers. Especially when we're asked about the ROI on our efforts to eliminate some annoying legacy stuff and build a new shiny module or service. Also, when we work on tech debt, we do want to tackle the most impactful parts of it first, don't we? This talk is about all of that: how we measure our tech debt, how we interpret the results of these measurements so that they give us the answers to the right questions, and how we guide our decision making with those answers.

This talk has been presented at TechLead Conference 2023, check out the latest edition of this Tech Conference.

FAQ

The speaker is Anton, a director of engineering at Westing in Germany and a mentor and coach for engineering leaders.

The primary topic is measuring tech debt and interpreting the results.

Tech debt is a tool to temporarily speed up development by cutting corners, at the expense of slowing down later.

The two types of tech debt are maintenance tech debt and continuous tech debt.

Continuous tech debt is immediately problematic as soon as it is deployed to production, leading to issues like bugs, downtime, and security breaches.

Heuristic metrics include cyclomatic code complexity, code duplication, code smells, maintainability index, tech debt ratio, and heuristically detectable security issues.

Second-tier tech debt metrics are metrics influenced by tech debt, such as effort split between ad hoc support and features, cycle time for feature tickets, bug trends, and software uptime.

Tech debt interest is the additional effort spent on tasks due to tech debt, calculated by comparing the effort required with and without tech debt.

Teams can collect tech debt interest by logging time spent on tickets, estimating effort without tech debt, and regularly updating this information in their issue tracker.

Second-tier metrics are important because they show the impact of tech debt elimination efforts and are essential for tracking overall team and software health.

Anton Kazakov
Anton Kazakov
27 min
09 Mar, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk discusses the measurement and interpretation of tech lead, focusing on tech debt. Tech debt is a tool to temporarily speed up development but can have negative consequences if not managed properly. Various tech debt metrics, including heuristic metrics and second-tier metrics, can help identify and manage tech debt. Tech debt interest is crucial for measuring the impact of tech debt and allows for prioritization. It is important to collect and analyze tech debt metrics to ensure software and team health.

1. Introduction

Short description:

Hi, everyone. My name is Anton, and thank you for having me at TechLeadConf this year. In the next 20, maybe 25 minutes, I'm gonna be talking about measuring tech lead and interpreting the results. I hope this talk will be useful and interesting for you. I lead engineering organizations and mentor other engineering leaders. Feel free to contact me for mentorship or coaching. Let's dive right in.

Hi, everyone. My name is Anton, and thank you for having me at TechLeadConf this year. And in the next 20, maybe 25 minutes, I'm gonna be talking about measuring tech lead and interpreting the results. I hope this talk will be useful and interesting for you.

The first couple of details about me, I lead engineering organizations. I am a director of engineering at Westing in Germany at the moment. And also, I mentor and coach other engineering leaders like engineering managers, staff principal engineers. So if you're looking for a mentor or for a coach, feel free to contact me, I'm always open. I'm also outside of work, I'm a father and a big fan of mountain skiing and hiking amongst other things. Down below you can see my Twitter handle and my contact info, like, email address and also the link to connect with me on LinkedIn. And yeah, with that, let's dive right in.

2. Understanding Tech Debt

Short description:

Tech debt is not inherently bad but depends on various factors. It is a tool to temporarily speed up development by cutting corners, much like taking a loan. To determine if we have tech debt, we can analyze our software and answer questions such as ease of analysis, modification, and safety. There are two types of tech debt: maintenance tech debt, which slows down changes due to imperfect design, and continuous tech debt, which requires time to keep the application operational. Continuous tech debt becomes bad when deployed to production, leading to bugs, downtime, security breaches, and lost revenue. Therefore, it is important to manage tech debt to avoid negative consequences.

Let's start with a shocker. What have I told you? Says our dear friend Morpheus, that not all your tech debt actually needs fixing. I fully support this statement, actually, oh, this question rather. And to understand how's that, how's that not all tech debt needs fixing and also how does it even contradict a relatively popular belief that tech debt is generally the root of all evil, let's look at a few things.

So starting with actually what is tech debt? If not, the root of all evil. It was the term coined by this guy, Ward Cunningham in 1992. And he was much younger at that time because this is a screenshot from his explainer video on YouTube that he posted in 2009. And the video is called Tech Debt Metaphor. And he's talking in depth, at large about it. And here are a couple of quotes, which we're not gonna read. We'll just skip over them. So just, according to Ward Cunningham, the author of the term tech debt, it is not the root of all evil. And what it is, it is a tool to temporarily speed up development in that we choose to cut corners to speed up now at the expense of slowing down later. Much like taking a loan, we can afford something earlier than we earn it fully, and then for that we have to pay interest. So since it's a tool, is tech debt inherently bad? Well, let's ask our dear friend Morpheus and he will tell us that the correct answer is it depends. So, as to many questions in the software engineering domain, well, how does it depend? That's the interesting part, right? What does it depend on, like how can we see what it depends on? Well, first, let's look at how we tell if we have tech debt in the first place. That we can do by looking at our piece of software and answering a number of questions. First, is it easy to analyze and understand? This piece of software. Second, is it easy to modify? Third, is it safe to modify? And finally the fourth question, are there any needed technical requirements, for example, scalability, stability, security requirements that aren't implemented? And if we have a yes to any of these questions, we do have tech debt in this piece of software.

Additionally, what I like to distinguish between are two types of tech debt. The first being maintenance tech debt. This is the tech debt related to the first three questions, which is basically the part of tech debt that is slowing down our changes, be it features or be it other types of changes in our code base. We're just implementing them slower because of the tech debt, because the design is not perfect. And the second part of tech debt is continuous tech debt. Which means that we need to spend some time, because of some tech debt in our application, we need to spend some time on keeping the application operational. And this tech debt actually shrinks the bucket of time that we can spend on introducing changes into our code base. So this is how these two types of tech debt are different, and this is how they differently define the answer to the question, when does tech debt become bad actually? Because not all of it is inherently bad, but when does it become bad? Well, continuing tech debt is immediately bad as soon as we deploy it to production. So any shortcuts, reliability, scalability, security shortcuts produce some first order consequences like bugs, downtime, security breaches, god forbid stolen data, which then in turn all produces ad hoc effort, context switching, which is, as we know, another popular productivity burner. Sometimes lost revenue, sometimes things that are even worse than that, like long term reputational damage and so on and so forth. So we don't want that.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Framework for Managing Technical Debt
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
Top Content
Watch video: Principles for Scaling Frontend Application Development
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
Fighting Technical Debt With Continuous Refactoring
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.
AI and Web Development: Hype or Reality
JSNation 2023JSNation 2023
24 min
AI and Web Development: Hype or Reality
Top Content
This talk explores the use of AI in web development, including tools like GitHub Copilot and Fig for CLI commands. AI can generate boilerplate code, provide context-aware solutions, and generate dummy data. It can also assist with CSS selectors and regexes, and be integrated into applications. AI is used to enhance the podcast experience by transcribing episodes and providing JSON data. The talk also discusses formatting AI output, crafting requests, and analyzing embeddings for similarity.
Building High-Performing Cross-Cultural Teams
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
The Talk discusses the importance of effective communication and collaboration in cross-cultural teams. It emphasizes the impact of culture on communication and performance evaluation. The speaker highlights the differences between low-context and high-context communication styles and the need to understand cultural nuances. It also explores the challenges of giving feedback in multicultural teams and suggests ways to improve communication and create a feedback culture. The influence of language on communication and the importance of transparency and honesty in feedback are also discussed.
Forget Bad Code, Focus on the System
React Summit US 2023React Summit US 2023
27 min
Forget Bad Code, Focus on the System
Top Content
Watch video: Forget Bad Code, Focus on the System
Setting up the system and separating concerns are important in software development. Modular construction and prefab units are a new trend that makes construction quicker and easier. Architectural complexity can lead to a drop in productivity and an increase in defects. Measuring architectural complexity can help identify natural modules in the code. Best practices for avoiding architectural complexity include organizing code by business domain and using prop drilling. Atomic design and organizing a monorepo are recommended approaches for managing architectural complexity.

Workshops on related topic

From Engineer to Leader: A Workshop for First-Time Tech Leaders
TechLead Conference 2024TechLead Conference 2024
144 min
From Engineer to Leader: A Workshop for First-Time Tech Leaders
Workshop
Andrew Murphy
Andrew Murphy
Transitioning from an individual contributor role to a leadership position, especially in the fast-paced tech industry, is hugely challenging. Most new leaders don't receive any training at all in the first 10 years of their new responsibilities.Our comprehensive workshop is designed to assist new and emerging tech leaders in understanding their new roles and gaining the skills to make them confident, happy and effective leaders.
Managers Are From Mars, Devs Are From Venus
TechLead Conference 2024TechLead Conference 2024
111 min
Managers Are From Mars, Devs Are From Venus
Workshop
Mo Khazali
Mo Khazali
A Developer’s Guide to Communicating, Convincing, and Collaborating Effectively With Stakeholders
It’s a tale as old as time - collaboration between developers and business stakeholders has long been a challenge, with a lack of clear communication often leaving both sides frustrated. The best developers can deeply understand their business counterparts’ needs, effectively communicate technical strategy without losing the non-technical crowd, and convince the business to make the right decisions. Working at a consultancy, I’ve both failed and succeeded in architecting and “selling” technical visions, learning many lessons along the way.Whether you work at a product company, are a consultant/freelancer, or want to venture beyond just being a developer, the ability to convince and clearly communicate with stakeholders can set you apart in the tech industry. This becomes even more important with the rise of GenAI and the increasingly competitive developer market, as problem-solving and effective communication are key to positioning yourself.In this workshop, I’ll share real-world examples, both good and bad, and guide you through putting the theory into practice through dojos.
Out of the Frying Pan, Into the Fire: A Manager's Guide to Helping New Developers Thrive
TechLead Conference 2024TechLead Conference 2024
35 min
Out of the Frying Pan, Into the Fire: A Manager's Guide to Helping New Developers Thrive
Workshop
Andrew Coleburn
Andrew Coleburn
Onboarding to a new project can be difficult, no matter your background and experience. But it can be especially challenging for new developers straight out of school or a coding bootcamp. Drawing on personal experience as a bootcamp grad and JavaScript consultant, this talk will discuss tips and strategies for managers to help the new developers on their teams get their bearings in an unfamiliar codebase, so they can make more of an impact, faster!