Making technical debt work for you
Some development teams – and start-ups in particular – think of their initial product as 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 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, the code changes and enhancements get larger and larger. There’s never a good time for a full 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 smart trade-offs and delaying optimisation, not building a product based on bad 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 some 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 a bad thing, but you need to be aware of the issue, thoughtful about your decisions, and ready to fix those technical problems as needed.
Good debt vs bad debt
IIt 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 major 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 difficult to make changes. Rather than quick, agile fixes, you have to 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, switching to a PaaS platform is an exercise in frustration. 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 no idea 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.
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 noticed until a customer complained. 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 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 obvious 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 important if you want 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 on an ad-hoc basis, 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.
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.