In , we looked at the macro trends that make tech debt inevitable. However, even though tech debt is a fact of life, technical bankruptcy doesn't have to be. So this time, let's look at the methods we can employ to avoid technical bankruptcy and save everyone a lot of grief, time, and money. the previous article Technical debt doesn't necessarily lead to technical bankruptcy. But it is where we'll end up if we don't fight the micro-trends that push high-growth software companies towards it. Companies typically don't take the right measures to avoid technical bankruptcy. They simply accept that it'll happen one day, and that when it does, they'll refactor their entire codebase in a giant project to deal with it. But, of course, these projects rarely go according to plan. Even though there is little we can do about the macro trends that make tech debt inevitable—we cannot change the laws of physics, as a fictional Scottish spaceship engineer might've said—there are plenty of ways to avoid the dreaded technical bankruptcy. To separate effective from ineffective solutions, we need to gain a deep understanding of the forces at play and their roots in sociology, criminology, and game theory. The micro-trends pushing us towards technical bankruptcy The Broken Window Theory Visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes. Wikipedia For our purposes, we can boil things down to this: . Tolerating even the smallest of offences will lead to it becoming acceptable behaviour and it will spread to the rest of your codebase like a crimewave. technical debt breeds more technical debt As we learned in , software entropy is forever increasing in any growing system. Therefore, so is technical debt. This makes it extremely hard—even impossible and unwise—to fix all the broken windows in your codebase and prevent a tech debt epidemic. The simple reasons tech debt is inevitable ‘The Tragedy of the Commons’ and ‘The Prisoner's Dilemma’ The tragedy of the commons is an economic problem in which every individual has an incentive to consume a resource at the expense of every other individual with no way to exclude anyone from consuming. It results in overconsumption, under investment, and ultimately depletion of the resource. Investopedia Software engineering teams are typically rewarded for delivering as quickly as possible on the tasks they were assigned. The resource they consume is . They're incentivised to go as fast as possible and therefore often take shortcuts, thereby creating technical debt which subsequently becomes everyone's problem. time However, since everyone is incentivised to keep shipping new features at pace, engineering teams won't have any incentive to step up and pay back tech debt. It's the prisoner's dilemma. The prisoner's dilemma is a paradox in decision analysis in which two individuals acting in their own self-interests do not produce the optimal outcome. Investopedia Both concepts are cases of self-interest harming the common good. Combined, they explain why tech debt usually remains unaddressed until it causes the whole software development machine to grind to a halt. ran through an interesting simulation of this problem in his article " ". Peter Merel The Tragedy of the PMO Once they go technically bankrupt, companies have no choice but to pay back technical debt, and because they didn't repay it continuously as they were shipping new features, they have to do it all in one massive project . . . or throw the code away and start from scratch. The problem with this approach is that the more complex and larger a project is—especially when it's riddled with technical debt—the harder it is to accurately estimate tasks. has written a great piece to help you tackle this: . David Bailey What NOT to do When Rebuilding your Tech Why typical solutions to this problem don't work Technical debt doesn't arise out of malice. And incompetence isn't as big a contributing factor as you might expect. We can't just tighten the screws on our engineering team and expect tech debt to go away. You probably know someone who's tried this approach and failed. In fact, none of the typical solutions to tackle tech debt work. Here's why. Tech debt isn't only engineering's problem to fix: Conway's Law Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations. Wikipedia We expect software engineers to manage tech debt properly. Yet the systems they design are constrained by the company's org structure—which they have little control over. Any changes in company structure and the way it communicates have to come from the very top, and if we're lucky, the people at the very top understand tech debt and take it seriously. But if they're like most people and they don't get it, we're in trouble. Add to this the fact that companies often suffer from organisational debt, which , and it's clear why engineers are set up for failure. Steve Blank deems even more deadly than technical debt Tech debt isn't always a bad thing: Knuth's Optimisation Principle [...] Premature optimization is the root of all evil (or at least most of it) in programming. The Art of Computer Programming by Donald Knuth Knuth's principle was originally concerned with the time code takes to run, but it is also a foundation of the Lean Startup and Agile methodologies, applied by so many modern engineering teams at high-growth software companies—and rightly so. It explains why taking on tech debt to avoid the horrors of premature optimisation is often the right choice, a topic you can dive into with our article about . But tech debt needs to be managed carefully, especially once a company reaches product-market fit. how to define effective tech debt budgets Timely optimisation is fantastic but it's also extremely hard to do when every incentive pushes you to quickly ship new features instead (see ). previous article Breaking the vicious cycle of tech debt Never, ever, think about something else when you should be thinking about the power of incentives. Charlie Munger The laws, rules, principles, and theories we've discussed all have one thing in common: they describe a set of existing incentives and their consequences. But the solution to the vicious cycle of tech debt is to fix a very specific set of incentives, to turn the tide in our favour. Use the Pareto Principle to prioritise tech debt It's likely that around 20% of the tech debt in your codebase accounts for around 80% of your problems (e.g. bugs, outages, etc.). As revealed in our article about , Microsoft Research has shown that while active files only make up 2–8% of the total systems, they are responsible for 60–90% of all defects. how to define your tech debt budget In other words, you don't need to tackle all your tech debt at once. Heed Linus Law carefully (he’s right, again) Given enough eyeballs, all bugs are shallow. Linus Torvalds Keep pull requests small so they're easy to review, and make sure the code is reviewed by enough of the right people (hint: probably ). That way, you'll catch most bugs before they even make it to production. people who own this code Celebrate tech debt heroes This one's simple. During Friday demos, don't just applaud the engineers who shipped new features. Cheer for the unsung heroes of tech debt: the people who refactored this nasty function, fixed that bug, reviewed these pull requests, and saved you from the seemingly inevitable destiny of technical bankruptcy. It's one of the stops on . your journey towards an engineering culture of ownership, and a healthy codebase Talk about tech debt across the company Company leadership needs to understand how tech debt impacts the whole company and the role they have to play in it. Only then will they take it seriously. As software engineers who understand technical debt, it is our responsibility to communicate it across the entire business. We'll talk about this in an article very soon, but in the meantime, take a look at Martin Fowler's excellent piece, ' '. Is high quality software worth the cost? The power of habits Notice how none of the advice above requires additional engineering work. In fact, it breaks the tech debt problem down into smaller habits that, if properly followed, will make everybody's job easier, faster, and more enjoyable. Champions don't do extraordinary things. They do ordinary things, but they do them without thinking, too fast for the other team to react. They follow the habits they've learned. Charles Duhigg, The Power of Habit: Why We Do What We Do in Life and Business Change small habits over time and your engineers will ship better code faster, you'll have happier customers who'll refer more leads . . . and you'll beat your competitors. To help you acquire these good habits, we built a free VSCode extension to continuously track and pay back tech debt. Get started now before it's too late!

Microsoft

Timely

200+ Software Engineers Taught Me The Best Way To Manage Technical Debt

Always Leave the Code Better than You Found It - Boy Scout Engineering 101

Track and prioritise technical debt. Create your free account at stepsize.com

Get the AI companion for software projects. Never miscommunicate again

Nominated for 2022 - HackerNoon Contributor of the Year - Frontend

Nominated for 2022 - HackerNoon Contributor of the Year - Code Quality

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - HackerNoon Contributor of the Year - Refactoring

Too Long; Didn't Read

Make resilience your competitive advantage

4 Simple Habits For Engineering Teams To Beat Technical Debt

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Navigating AI Adoption: A Strategic Four-Step Plan for CTOs

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

Navigating AI Adoption: A Strategic Four-Step Plan for CTOs

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps