Striking a balance with tech debt

Some software development teams – particularly start-ups – consider their initial product a temporary, throw-away version of their system. The first implementation is an experimental MVP made to test the market. Once the market is proven, it is rewritten from scratch.

The approach has a certain appeal, but it also means taking on a mountain of technical debt. If you throw out the initial MVP, you're right back to where you started, with customers and investors breathing down your neck as you develop your product all over again.

That's why, in most cases, the full rewrite never happens. Instead, you add small features and improvements to the MVP, and the code changes and enhancements get larger and larger. There's never a good time for a complete rewrite, so your experimental MVP becomes your product – with all the technical debt still waiting to be resolved.

Managed well, incurring technical debt means making intelligent trade-offs and delaying optimisation, not building a product based on lousy code and shaky architecture.

A better plan for technical debt

Technical debt is the future cost of shortcuts or workarounds taken today. When developing a product, you'll use quick fixes and limit some features to get it to market. At least, you should – and tech debt is the result. At some point, you'll need to 'repay' your technical debt by going back, reworking and restructuring your software to get it up to speed.

It's not bad, but you must be aware of the issue, thoughtful about your decisions, and ready to fix those technical problems as needed.

Good debt vs bad debt

It can be hard to tell whether you're taking on 'good' or 'bad' technical debt while in the throes of product development. 'Good' technical debt is worth the trade-off because it helps you move toward a product launch and get an MVP out there. The faster you do that, the easier it is to optimise your product and repay your debt.

Here's what 'good' technical debt looks like:

• Minimal rework:  shortcuts help you save time now but will be relatively easy to fix later.
• Solid architecture: 'Tech debt' isn't an excuse for lax code or a weak underlying structure. If you've taken on 'good' tech debt, you should be adding features and optimising, not going back to change huge swathes of weak code.
• Fewer system changes: automated testing during development can help strengthen your initial code and lower your risk of significant system changes later.

In contrast, 'bad' technical debt happens when your development decisions lead to major changes and excessive rework down the track. 'Bad' debt can also come in with premature optimisation. By over-engineering and creating a complex product before it's needed, you can slow your development process and make it more challenging to make changes. Rather than quick, agile fixes, you must dive into complex software architecture for every minor change.

'Bad' technical debt often comes from these key decisions:

• Implementation language:  it's impossible to change a programming language without rewriting your entire system, so get it right from the beginning. Picking the right language is simple: use the one your development team knows best.
• Database platform: developers know that migrating a working system to a new database platform is difficult, time-consuming and hard to test. Choose a platform with the capacity to scale, even if it costs more or takes a little longer to implement.
• Deployment platform: as with database platforms, switching code between deployment platforms can be complex and time-consuming. For example, if you develop software that requires being run on a virtual machine, changing to a PaaS platform is frustrating. Think about the platform you want to use for your final product and start there.

Planning for tech debt

You've got your MVP out there, grown your customer base, and your business is thriving. The bad news? It's time to repay that technical debt. If you've been through a complex development process and you're scrambling to keep up with your business, you may have piles of tech debt and need help figuring out where to start fixing it.

The first stage is to identify critical problems and prioritise those you need to fix first. From there, you can tackle each issue with a four-step approach.

1: Deconstruct
Defining the problem and breaking it down into its elements is crucial. Imagine that you have a bug where welcome emails are not being sent to a large subset of new users, and nobody notices until a customer complains. Your engineers identify the problem as a microservice failing to record new accounts – a relatively quick fix. However, the problem points to several deeper issues that could negatively affect the system in other ways and cause many more problems. For example, an unmonitored queue and a lack of automated testing in your system. These issues are also technical debt and need to be resolved.

2. Decide and document
After you have deconstructed the problem and pulled out key issues, you need a plan. Usually, you'll start with the most prominent issue – fixing the code that is missing new users. But you also need a plan for the other issues. If you don't have the time to fix them now, document them so you can resolve them later.

3. Plan and prioritise
Create a ticket or document for each technical debt item and prioritise it based on urgency, capacity, cost and ongoing impact. With the email example, a code fix will resolve the issue for customers, but a wider look at monitoring and automated testing is essential to avoid similar problems down the line.

4. Fix the issue
All the planning and documentation in the world won't help if you don't actually fix the issue – and all the other technical debt problems on your list. Instead of tackling these ad-hoc, many companies include technical debt resolution in their regular budget, giving development teams time to work on fixes.

Staying on top of your tech debt

Your technical debt account will never be at zero – there will always be a new trade-off or shortcut, even as you resolve older issues. The best approach is to understand, anticipate and manage your technical debt to minimise the impact on your business.

What is the upside of technical debt? It's a sign that your business has grown beyond what you imagined at the outset. Every new issue shows that your assumptions about system load and customer numbers were wrong – and that's a reason to celebrate.

Need help managing your technical debt as you scale? Talk to a Parallo Solutions Architect. We know how to manage tech debt.