*Originally published on Entrepreneur https://www.entrepreneur.com/leadership/beware-rebuilding-is-not-the-only-solution-for-overcoming/381962

Five tactics that will guide you to recognize signs of tech debt and the risks involved while making you a mature decision maker.

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. 

Be it Martin Fowlers popular book about Refactoring: Improving the design of existing code or blogs from Justin Fuller or Joel Spolsky or David Boyne  have expressed similar thoughts.

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”, “next release” on a consistent basis. They are easy to select from a drop down menu of your task tracking software, but 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, it’s time to intervene and clean up.
    • Price you pay: Lack of emotional safety, security, ownership and accountability culture.

Here are some real examples of tech debt my teams have dealt 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 to Near Real Time Search Engine using Solr.
• Unable to clearly follow the full life cycle of a request.
• One data model overfit to support multiple use cases. ( Most common use case 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 exec 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 5 tactical considerations:

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 Archaeologist. Make a list of what is Intentional vs 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 he says it’s a good way to get a team to start documenting and understand the domain they are operating in.

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.

Break it down

Start small, maintain parity with the old functionality and 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.

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”. Inorder to build functional domain expertise with your new team a simultaneous Rebuild acts as 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 2 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. But 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, and 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 neave. 

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 one tends to avoid maintaining the code as a result. 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. 

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.