Investing in Tech Debt: Choose Wisely
Let’s say you are a software architect for an online PDF search company. Customers pay per gigabyte for storage of their documents, and our search application backs them up and makes them searchable. The user front-end for your product uses Thymeleaf templates to render the UI server-side, however when your product team asked for the ability to tag documents, the dev team insisted a migration to React was in order. The migration may add another two weeks of work to this feature, but it is simply too painful to slog through server-side templates… and it would make each additional feature easier to implement.
As the software architect, you need to make a decision to either a) plow forward and implement the feature with the current technology stack, while possibly incurring more tech debt, or b) move to the new web client framework and take a hit to your release timeline. Which do you choose?
Even if you are starting a greenfield project or a new tech company, the decision of prioritizing tech updates over new features appears early and often. With a lean crew it’s crucial to focus attention on the things that make the biggest impact and highlight the core value of your product. It is true that there are some critical decisions that greatly reduce your agility if you get them wrong… decisions that will can cause product development to grind to a halt when you need to change direction. Then again, there are many occasions where the choices that don’t end up mattering are the decisions that eat up the majority of a new company’s tech design time.
Opportunity Cost and Business Value
Choosing the right UI framework, landing on a standard build chain, even your analytics and reporting — it’s usually best to do a quick comparison of your options and swiftly move on. Here “designing for the future” is less important than building something now and gaining momentum. A useful way of deciding if you should go forward with a new tech direction is to evaluate the effort based on its opportunity cost and its business value.
Opportunity cost can be considered time and effort that could have been spent on something else. If two developers spend four weeks moving your client APIs to WebSockets, they are otherwise unavailable to work on building self-service features that your customers may have requested. Your developers weren’t necessarily “too busy to work on other things,” instead your team decided it was more worthwhile to spend the opportunity on WebSockets support than on customer features. This isn’t necessarily a bad thing — but time and effort are precious resources that need to be managed wisely.
Business value is the ability for your organization to either reduce cost or increase revenue. The self-service features that your customers request may provide business value by reducing your company’s administrative overhead and provide better user engagement, while a WebSockets transformation may offer a smaller business value through reducing UI wait times and alleviating network congestion.
When measuring the next big “tech debt” fix, ask the following questions:
- Will this improvement reduce our opportunity cost going forward?
- Will this improvement increase or help realize business value?
The False Economy of Tech Debt
You can reduce opportunity cost by making sure developers can work in a way that they find most efficient and by allowing them to deploy autonomously. Rather than relying on a chain of command, we can construct software in such a way that it can be reviewed by peer developers for defects and easily tested in an automated fashion. Once we can have greater confidence in code quality and reliability, giving a team the responsibility to push changes into production or pre-production environments allows for independent releases of new features.
Allowing for tech improvements that move you away from a single, monolithic application into a cluster of isolated services allow these new features to exist and evolve independently; by evolving independently, teams can determine their own ideal tools and frameworks rather than building towards some global idea. The recently published Accelerate: The Science of Lean Software and DevOps has provided some empirical evidence that “teams that can choose their own tools based on what is best for the users of those tools” have a “strong and statistically significant impact” on their ability to rapidly deliver high-quality code. When it came to designing a new company or large project, Accelerate noted that picking between Node.JS, Scala, or Python was less important than breaking your data apart by domain and across multiple databases and data sources. Such an architecture includes the use of “bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units” as a way of reducing opportunity cost.
To realize business value you need to make features publicly available as well. A feature that is code complete but not yet deployed has no inherent business value, since no one can leverage it yet. Just as cash sitting in a coffee can loses value without investment, features depreciate business value as they sit undeployed. After spending large amounts of capital on engineers and managers when building a feature, quarterly or monthly releases stop businesses from realizing its business value as code sits unused. Treating your infrastructure and deployments as code by focusing on continuous deployment and DevOps methods allows for reliable and repeated deployments, even during business hours.
Choose Wisely
Consider again the example of our budding online PDF search company. Here the opportunity cost for moving to React may not only be pushing back our tagging feature, but also the release date of our new image recognition features. If we sacrifice two weeks of developer time for the migration, will we be able to release items out of our backlog faster? The image recognition capabilities could help us sell to enterprise clients — and so here the opportunity cost of migrating may be too high right now. Our back-end computer vision engine won’t benefit from the UI framework changes, and so we may not realize business value any faster. The intrepid architect should hold off on the React migration for now… but soften the blow by catering in a nacho bar. As development continues, and the team grows confident that two weeks of developer time can accelerate feature development by more than two weeks, we may want to re-consider our decision and re-prioritize the refactor.
If a tech improvement can help the business reduce opportunity cost and more quickly realize business value it can be judged as a worthwhile investment. Otherwise — you may just need to let it go.
High Alpha is a venture studio pioneering a new model for entrepreneurship that unites company building and venture capital. To learn more, visit highalpha.com or subscribe to our newsletter.
