Digital Stories

Tech debt: can’t live with it, can’t live without it.

If you’re a non-tech person who’s involved in building a software product, you’ll soon reach this verdict. As you try to push a successful product to market, you’ll discover that aligning stakeholders’ expectations, customer needs, financial constraints, deadlines, and tech requirements will often require trade-offs. Most of the time, these “bargains” will mean cutting corners in the development process.

In the short term, your tech trade-offs can deliver the expected outcome: you’ll put a product to market sooner rather than later. But in the long-run, accumulating “tech debt” can slow-down your work and cause more harm than good. So, in a world where you want everything (tech-perfect, fast-to-market products), how can you deal with real-scenarios and make things work?

To solve this puzzle, we’ll explain what tech debt is, when it’s a necessary evil, and the consequences of not paying it (spoiler alert: you always should pay it).

What’s debt got to do with tech?

Tech debt happens due to prioritizing a speedy and imperfect outcome over a longer, more refined, and substantial development process. At first glance, this might sound like a perfectly reasonable thing to do. After all, your interest is to reduce costs and timings to start gaining revenue from your product. Alternatively, project constraints pressure you only to achieve milestones, and 100% product perfection is not your goal.

Fair enough. However, while prioritizing is okay, the story behind tech debt is not that simple.

In essence, tech debt appears after a “quick fix” meant to shorten delivery time. The reverse of the coin is that these shortcuts accumulate “interest” and, in time, weigh heavily on the software’s quality and efficiency.

Think about tech debt as cutting tech corners with the goal of borrowing time. However, sooner rather than later, you’ll be asked to repay that time. Maybe you’ll want to develop a new feature. Maybe you’ll want to address user complaints. Or perhaps you’ll simply want a product upgrade.

These are just a few cases in which tech debt will come out to ask for its share. In these moments, the fast-tech-solution you opted for will get developers back to square one, as they’ll need to write not only new code but rewrite the “quick fix” as well.

Why are software developers so dreary of tech debt?

Oh, where to begin? The reasons are bountiful, and they hold water.

To start, think about the expectations you have from your software team. No doubt, you want your UX designers, product engineers, and developers to be amazing. However, being excellent stems from having strong skills and even stronger software values.

Great software teams are great because they care about best practices. They’re eager to work with new technologies and want to bring industry progress to customer products. The best software teams want to dig deep into software architectures and build flawless products with clean code. Aaaand they’re not big fans of shortcuts because these imply delivering less quality than they could.

Now, an important distinction that our software teams always want to make is that tech debt doesn’t equal a “mess.” A mess is just a mess. Still, tech debt does mean unpolished code that is not 100% aligned with best practices. It also implies dealing with code that accumulates weaknesses that will need to be addressed at some point.

Why should you care about tech debt?

Project constraints are real. Sometimes, no matter how much you’d love to have all the time in the world to build your software products by the book, you’ll have no choice but to be sensitive to market realities, investors’ requirements, and business deadlines.

That means that tech debt can be a reasonable solution — in exceptional cases — as long as there’s a thorough repayment plan to back it up. Otherwise, borrowing from your future tech solution will only seem like progress at first.

Accumulating too much tech debt will harm your business in several ways:

• It can provide a false sense of achievement. Sure, you’ll manage to achieve your milestones, but the result will fall flat after some time. This will be visible in your ROI and overall user satisfaction.

• Tech debt makes it harder to implement changes later on. For example, in case of an upgrade, before you’ll be able to write a new code, you’ll have to mend the previously “patched” one. That means your costs will go up, and deadlines will be pushed.

• Maintenance itself will become a daunting task. Tech debt can lead to bugs that are hard to track and a nuisance to solve. By cutting down on delivery time, peer reviews and testing become a luxury, so faulty pieces of code can easily make their way into the final product. With more maintenance work to do, your bills will pile up.

How can you avoid tech debt?

Having the right software team by your side is essential. You want a team that doesn’t just say “yes” whenever you want to lean into tech debt. Instead, you want a team that understands both business needs and technology requirements and can balance the two to deliver a quality product. Ideally, such a software team should include business analysts, product engineers, UX designers, and software developers.

To avoid tech debt, you first need to admit some hard truths about what it takes to build a successful product. You need to keep a flexible mindset and be open to explore new ways of approaching your development process. For example, a discovery phase can be a great way to address issues. Compared to tech debt, even if a discovery phase requires more time at first, it delivers more quality later on. Continuous development is another approach that can help you deploy products faster and without hindering their quality. By entering a reiterative development process, you can automate and streamline your software efforts.

The most important thing to remember when dealing with tech debt is that it is what you make of it. It’s neither inherently good nor bad. If necessary, prioritize and borrow time, but always pay it back. If not, remember that other development approaches could take you out of unwanted debt.

In the end, discussing things openly with a software team that’s keen on quality but also has your business interest at heart will always show you the right way. It’s up to you to take it.