A Bit About Technical Debt

So… What Exactly Is Technical Debt?

Technical debt (commonly referred to as tech debt) is the actual or implied cost of additional rework caused by choosing an easy or limited solution now instead of using a better approach that would take longer. Sure, tech debt may seem like the easy way out when you’re in a time crunch but you’ll certainly feel the pain of those decisions later. You’ll be wondering how we got here.

When Do We Want It? Now! What Do We Want? I Don’t Know!

In my years of experience, I’ve come to understand that technical debt is an inescapable business decision. Here are some of the decisions that lead to the accumulation of tech debt:

• Rushed Releases and Tight Deadlines: There always seems to be a disconnect between business stakeholders and technical stakeholders and in many of those cases, a business stakeholder will decide that they want a product to be created or updated with certain features, and that usually isn’t a problem. The problem comes when they also decide that they want this product finished by a certain date. Everyone in this situation should understand the underlying technology it takes to make it happen, or perhaps the expertise needed to get the job done. Perhaps it would lead to more reasonable deadlines. Oftentimes these deadlines are set before requirements are even formalized. The result becomes a situation where technical stakeholders begin actively building a product without fully understanding what is required.
• Lack of Standards and Documentation: 10 different developers will write the same functionality 10 different ways. That makes sense because we’re all different but if you’re working in a collaborative environment, it would behoove you to implement infrastructure, coding, testing and documentation standards.
• Bleeding Edge or Legacy Technology: There is a fine line we have to navigate when implementing technology. If you hold on to legacy systems written in older languages, it may become difficult to run that legacy code on modern hardware. It may also be difficult to find developers who are capable of maintenance. On the flip side, adopting a new technology or language too quickly may leave you relying on buggy, unproven, or un-scalable software. There may not be enough developers who have learned the new technology yet.
• Evolution: I’ve been fortunate to be in a position to help other developers think through scenarios that would otherwise become tech debt. Sometimes I just ask simple questions like: “That code works well, what happens if 400,000 people need to run it all at once?” or “That function makes sense for what we’re solving now, how could we update it to take parameters to serve other scenarios in the future?” The need to scale and adapt to user demands happens ALL THE TIME! While we can’t account for every possibility, there are many things we can do to plan for the future.

Why Should You Care?

Technical debt isn’t going to go away if you ignore it. It would be in the best interest of yourself, your team and your company to identify and address technical debt proactively. Here are a few reasons why you should care:

• Slower Development: Quick and dirty solutions are often less readable or harder to understand. When developers revisit the code, they have to spend more time figuring out what’s going on, which delays the work. Also, If the initial design was rushed, there could be workarounds or hacks in place to patch issues. These are often fragile and may break easily, requiring more effort to fix when something goes wrong.
• Decreased Developer Morale: There is a reason you see so many people with the word “enthusiast” in their bios. Most of us got into technology because we love it. No one (that I know of) wants to start their work day dreading the code that they’re about to work on. I’ve always believed that happy employees make happy customers and if you’re in business to make money, you certainly want happy customers.
• Increased Risk of Bugs: The more tech debt you take on, the more complex and error-prone the code becomes.
• Scaling Problems: Buggy code doesn’t scale well. It just doesn’t. Need I say more?
• Higher Maintenance Costs: Tech debt is financial debt! Tech debt is financial debt! Tech debt is financial debt! Tech debt is financial debt! Did I say it enough times? Good!! I’ve witnessed situations where developers have spent more time fixing issues than implementing new features. Imagine having nearly 2 million dollars worth of salary in a conference room or on Zoom trying to solve an issue. That tech debt is literally costing the company money.

What Can You Do?

Technical debt is an inevitable business decision. That decision, as the great Drew Schillinger often says, becomes a “balance of headaches”. Do you want the headache of taking the extra time now or the headache of taking the extra time later to fix potentially poorly performing buggy code? Sometimes taking on tech debt is the right choice in order to hit a tight deadline or validate an idea quickly but you’d want to distinguish between tech debt that will be paid back soon and debt that could grow into a major problem if not addressed. I don’t believe there is a developer on the planet that hasn’t had to contribute to tech debt in their career. Sometimes you have to write code that makes you cringe, and that’s ok… just don’t ignore it. Here are some ideas to help navigate making tech debt decisions:

Identify the Debt

• Code Reviews: Red flags in code quality, readability, and maintainability.
• Monitoring Performance: Tools to measure system performance and identify bottlenecks.
• Feedback from Developers: Regular check-ins with the team about challenges they face.
• Test Coverage Gaps: Lack of automated testing could indicate areas of tech debt.
• Outdated Dependencies: Out-of-date libraries or frameworks that need upgrading.

Pay Down The Debt

• Prioritize Tech Debt: Evaluate which debt should be addressed first (e.g., business impact, urgency).
• Refactor Regularly: Encourage incremental improvements rather than large-scale rewrites.
• Allocate Time for Maintenance: Dedicate resources in every sprint to work on tech debt.
• Automate Tests and CI/CD Pipelines: Use automation to reduce the risk of introducing bugs while refactoring.
• Documentation and Knowledge Sharing: Keep systems well-documented and ensure teams are aligned on standards. Specifically note when something should be refactored due to technical debt.

What Has Been Your Experience?

What have you done to navigate tech debt in your career? When did you make the right call? What decisions do you wish you could take back? Leave a comment and let me know.