Identifying the Many Faces of Tech Debt

Problem

"Tech debt can creep up on you and end up hurting you in the following noticeable ways."

• "Productivity becomes slower and slower. Features that used to take 2 weeks to develop now take 5 weeks because your codebase becomes un-maintainable and difficult to work with."
• "Your feedback loop gets slower and slower and it impacts the agility your team had when it was first building the product. Build times get slower, database schemas become hard to manage, the code becomes more complex to maintain and even harder to write new features with it."
• "You will end up having large and slow release cycles with big bang deployments which cause high levels of stress. As the changes are so large those releases tend to be off schedule and cumbersome."
• "Each new feature and code change introduces new bugs because your system has grown to be unmaintainable and it is even harder to test."
• "Management teams need predictability and stability. With technical debt you will be pushed to have either. Team velocity is continually lower or slow and always hard to predict due to continuous issues with the system and interruption to development time."
• "People get frustrated with your product and so will your team. Good people don't like working in unhealthy software systems. They don't like working in spaghetti code on outdated tech stacks. Engineers will burn out and get sick of fighting against a bankrupt tech stack."
• "A code smell or stench in your code or system that is normally flagged by people complaining about what they are working on. A debt smell could be considered a red flag on your product."

Actions taken

"Tech debt can't always be stopped in time to resist the harm that accompanies it. The following however, are some ways to recognize the symptoms and indicators of tech debt in your platform early on."

• To-dos and fixme's in the code
• Can only be changed by X (Knowledge island)
• Copy paste, similar code everywhere.
• Spaghetti code.
• "I don't want to touch it and I don't know what will break" — bad design that inhibits change.
• Changes which would be fast on a green field project take much longer on yours
• Old libraries and use of deprecated API's
• Slow tests — or even worse, no tests
• Slow build system — or even worse, no build system

"Alongside these specific indicators, the following four quadrants identify how you can arrive in a situation of having large technical debt and the mindset engineering teams have when this happens. This quadrant is normally driven from experience (perhaps lack of) or pressures from the business."

• Reckless — Can come from management decisions (like hiring outsourcing companies to build your product) or engineering decisions like putting every line of code in one file.
• Prudent — normally comes from pragmatists who make decisions for the good of the business in order to hit its goals or from engineers who can see that taking the debt up front is more important than a perfect system.
• Deliberate vs Inadvertent — is the conscious decision to take on technical debt versuss just not having the experience to foresee it coming.

Lessons learned

"Tools like Sonar and Structure 101 exist to help you analyse tech debt issues and track progress. They give you historical data and coverage of tests; you can even make the build fail if quality degrades which stops these types of issues arising in the future. You can't understand the quality of your system without continual feedback with the people working day to day on the systems."

"Most studies in the field of tech debt have boiled down tackling this debt into three principal areas."

• Debt repayment — is when you decide to refactor or replace it. Only if the code is really bad you need to make it much more usable and extendable. Not something to be taken lightly, Joel Spolsky's piece on the Netscape 6.0 rewrite says this is the "single worst strategic mistake that any software company can make".
• Debt conversion — when you have critical areas of your system that replacement is not an option you take on fixing pain points to make it more usable and adaptable for the future. Happens when you can't afford the ideal solution, it's not worth the cost or time is a constraint.
• Accept it — When you know things aren't great but we can deal with it. The cost of changing everything is more expensive than working with an ok codebase. The value of investing in its debt brings little value.

Source