Heuristic, second-tier, and tech debt interest metrics.
Strategies for prioritizing tech debt fixes.
Tech debt is often seen as the bane of software development, but it's more nuanced than that. The term 'tech debt' was coined by Ward Cunningham to describe a strategy where developers take shortcuts to accelerate development, knowing that these shortcuts will need addressing later. This concept is similar to a financial loan; it provides immediate benefits but requires repayment with interest over time.
Not all tech debt is inherently bad. It depends on various factors, and understanding these can help in making informed decisions. The first step is identifying whether a piece of software has tech debt. This involves evaluating if the software is easy to understand, modify, and meets all technical requirements like scalability and security. If any of these criteria aren't met, tech debt is present.
Tech debt can be categorized into two main types: maintenance tech debt and continuous tech debt. Maintenance tech debt arises when poor design slows down future changes. Continuous tech debt impacts the ongoing operation of the application, leading to issues such as bugs, downtime, or security breaches. Continuous tech debt is problematic as soon as it hits production, whereas maintenance tech debt becomes an issue only when changes are needed in the affected areas.
The key challenge is determining which tech debts need immediate attention. This is where tech debt metrics come into play. They can be divided into heuristic metrics, second-tier metrics, and tech debt interest.
Heuristic metrics are automated and include measurements like cyclomatic complexity and code duplication. These metrics provide a quick overview of the codebase's health. However, they don't directly indicate the amount of work needed to resolve the tech debt or its business impact.
Second-tier metrics focus on the outcomes influenced by tech debt, such as the time spent on ad hoc support versus new features and cycle time for feature tickets. These metrics help prioritize tech debt fixes against business features since they reflect the broader business impact.
Tech debt interest, a concept introduced by Martin Fowler, involves estimating the additional effort caused by tech debt on a ticket-by-ticket basis. It offers a clear view of how much tech debt is affecting productivity and helps in prioritizing fixes based on business impact.
Effective management of tech debt requires a combination of these metrics. Tech debt interest is central as it offers a direct link between tech debt and business impact. Heuristic metrics provide a general health check of the codebase, while second-tier metrics help track the effectiveness of tech debt elimination efforts.
By systematically using these metrics, software teams can identify tech debt hotspots, calculate the return on investment for fixing them, and make informed decisions on prioritizing tech debt resolution against new feature development.
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.
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.
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 speaker is Anton, a director of engineering at Westing in Germany and a mentor and coach for engineering leaders.
Link to the mentioned "Estimated Interest" article: https://martinfowler.com/bliki/EstimatedInterest.html
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.
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.
2. Understanding Tech Debt
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.
3. Understanding Tech Debt Metrics
Continuous tech debt is immediately bad, while maintenance tech debt becomes bad when changes are introduced in the affected area. Tech debt metrics, including heuristic metrics, second tier metrics, and tech debt interest, help identify and manage tech debt. Heuristic tech debt metrics, such as cyclomatic code complexity and code duplication, are automated and provided by existing tools. These metrics can be divided into maintenance tech debt and continuous tech debt. However, converting these metrics into the actual work required to address the tech debt can be challenging.
4. Understanding Tech Debt Metrics (2)
Then, it's hard to convert tech debt metrics into business impact. Prioritizing hotspots based on these numbers alone is insufficient. Second-tier tech debt metrics include effort split, cycle time, bug trends, software uptime, and mean times. These metrics are directly connected to business impact, allowing for prioritization. However, they are generic and challenging to connect with specific code modules. The third bucket introduces the concept of tech debt interest, focusing on the ticket level to understand its impact.
5. Calculating Techdebt Interest
And with the team that has worked on this ticket, we can estimate the effort it would have taken without Techdebt. The difference between the two is Techdebt interest. We estimate Techdebt interest for all tickets, considering bugs and new functionality. This allows us to calculate the actual overhead and business impact, enabling ROI calculation. To collect Techdebt interest, ensure time logging and add a field estimation to every ticket. Repeat the exercise regularly to have data at your fingertips. Techdebt interest is directly connected to business impact and eases prioritization within the Techdebt bucket.
6. Using Tech Debt Metrics
Among the cons, it's relatively cumbersome to collect and opinionated. The metric is based on the work log, blind to unworked parts. Tech debt interest is crucial for measuring the impact of tech debt. It provides an educated prediction and eases cross prioritization. Heuristic metrics give an overall idea of code base health and are useful for estimating potential tech debt impact. Second tier metrics show the impact of tech debt elimination efforts. They are indispensable for tracking team and software health.
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.
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.
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.
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.
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.
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.
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.
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.
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!
Comments