Beware: Rebuilding is Not the Only Solution for Overcoming Tech Debt Five tactics that will guide you to recognize signs of tech debt and the risks involved while making you a mature decision maker.
Opinions expressed by Entrepreneur contributors are their own.
What do you do as a technical leader if you weren't there from the very beginning? Or if you weren't the one to write the first line of code? How do you make future tech decisions without knowledge of the past? Don't let pressure or lack of patience drive you to blindly choose the rebuild route. There is hope.
This article will guide you to recognize signs of tech debt, risks involved and help you consider five tactics to increase your overall Tech Quality Quotient (TQQ) and make you a mature decision maker.
Today's tech is tomorrow's debt. It's just how software lives its life. However, compromised code quality can bring product development to a grinding halt, the engineering team to its knees and cause the kind of mounting frustration that leads to talent attrition.
We have too much tech debt. "Let's rebuild the entire system and do it right this time" seems like an appropriate response when you are in the middle of it all. An emotion-driven choice to rebuild could turn into a trap if you aren't prepared.
Martin Fowler's popular book Refactoring: Improving the Design of Existing Code and blogs from Justin Fuller, Joel Spolsky and David Boyne have expressed similar thoughts.
Related: There's No Such Thing as a Bug-Free App
Signs you have tech debt
- Your current team did not write the old code nor do they understand it.
Price you pay: Lack of familiarity of the problem domain can result in difficulty scaling and debugging issues.
Pace of change is negatively affected and every release breaks more things than it fixes.
Price you pay: Cost of not being able to expand the architecture to scale
Developers do not want to work on your tech stack and you cannot find talent with the required skill sets.
Price you pay: Technology professionals want to advance their skill sets with cutting-edge technology. Finding someone to maintain old systems is harder and costlier.
You rely on manual customization and administration.
Price you pay: Manual solutions can never scale at the speed of technology.
You default to decisions such as punt, not to be fixed or next release on a consistent basis. They are easy to select from a drop down menu of your task-tracking software. But, they can have a lasting impact on the psyche or your organizational culture.
Price you pay: Missed opportunity due to slower dragged-out development cycles.
You break, you own fallacy: When you notice team members are fearful to touch pieces of code. Either because they fear breaking existing functionality or owning future maintainability. If so, it's time to intervene and clean up.
Price you pay: Lack of emotional safety, security, ownership and accountability culture.
Here are some examples of tech debt my teams have dealt with in the past:
- Tightly coupled Frontend and Backend
Migrating to state of art Frontend Technology — ES5 to Next.js
No CI/CD pipeline
Lack of Application and System-level observability
Lucene-based offline batch indexer VS Near Real Time Search Engine using Solr
Unable to clearly follow the full lifecycle of a request
One data model overfit to support multiple use cases. (Most common use case is combining Notification, Inbox and Messaging models as one.)
More than one tech solution to do almost the same thing
Tanking developer productivity and satisfaction
No engineering leader wants to convey messages to their executives and board members that there will be no new feature development. Yet, Apple in 2018 was forced to do just that. Apple, in their 2018 WorldWide Developer Conference, announced they were going to reduce feature counts in the upcoming iOS releases to concentrate on quality, security and performance. This suggests they are sacrificing new features for what should have been there in the first place.
Avoiding paying off your tech debt is bad, jumping the gun to rebuild from scratch is even worse. The reality is that old code has been used, tested and bug fixed. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of hard work.
Here are five tactical considerations:
1. Build a good digital transformation strategy
You will hardly find yourself in a state where you can throw away your entire product implementation. Most often you will be battling decisions about augmenting the competencies built in the past with new capabilities that offer competitive advantage in the digital economy.
Do your ground work like an archeologist. Make a list of what is intentional versus accidental. What can be replaced and what needs to be worked with. A good digital strategy should enable both. David Boyne suggests using Event Storming. I haven't used it yet but David says it's a good way to get a team to start documenting and understanding the domain they are operating in.
2. Customer retention risk
Will your customers adapt to your new system? Are you slowing them down? Customers don't care if things are written in PhP, angular or React, they care if the application helps them get their job done.
- Shortly after its 2011 IPO, LinkedIn's infrastructure almost collapsed. LinkedIn initiated Project Inversion to address its decade-old technology that needed a major overhaul. LinkedIn's technology revival has come with some costs, including constant changes that have bothered some users.
3. Break it down
Start small, maintain parity with the old functionality. Build a system that allows you to switch off new changes and fall back to the old if you discover unexpected behavior.
Incremental upgrades offer a good strategy to avoid major downtimes. I am a big proponent of Kaizen, a Japanese concept. It means continuous improvement and is still key to Japan's strength in maintaining high product quality.
4. When might you consider the rebuild route?
When you don't have the same programming team that worked on version 1, or you don't actually have more experience. In order to build functional domain expertise with your new team, a simultaneous rebuild acts as a training ground.
Encourage learning in a small, yet controlled, environment by breaking things and building them up again. How small do you break things is something you will get to decide based on your expertise to handle risks.
When you're dealing with core architectural changes.
Low costs of hosting: Due to innovation in cloud computing, maintaining two systems simultaneously is more cost-effective than ever with traffic bifurcation for Beta testing.
Instagram experienced this early on when it originally launched its iPhone app, running its operations off of a single server in Los Angeles. After an onslaught of traffic nearly crashed the server, Instagram pivoted (in three days!) to an EC2-hosted database, adding the additional resources to keep them moving. Co-founder Mike Krieger compared the transfer to open-heart surgery. He vowed that going forward they would preemptively address technical debt before it leads to catastrophe.
Last but not the least, don't forget about the most important aspect of it all. The mindset and cultural weave.
5. What's in it for me
As a leader you stand to gain a lot if you treat tech debt cleanup as a top-level strategic responsibility of the organization. Attach special incentives to make your team want to do the work. If you create a culture where flashy features are funded, recognized and awarded over fixing existing systems, why would anyone want to take on that work for you?
People fear rework, teams want to code once and forget about it. This tendency is not good because as a result, one tends to avoid maintaining the code. Redefine development as a repeatable process of going back to features every iteration and improving or addressing changes. Don't leave your features behind. They cannot be coded and forgotten. Change your team's mindset towards continuous development.
Related: How AI Will Transform Software Development
Conclusion
There's no silver bullet to solving tech debt. It's not a once-done task. It requires ongoing commitment, leadership buy-in and to be part of daily technical hygiene habits. Don't risk tech bankruptcy — pay off your tech debt by addressing outcomes towards significant performance, stability, security and maintainability gains.
Related: Why Do Huge Companies Such as Google Still Have Bugs in Their ...
