How to minimize new technical debt

With best practices and a commitment to not let technical debt grow, developers can make a solid business case, especially when staffing and money are tight.

Technical debt can be small, like minor code improvements to improve performance, code readability, or other support factors. Large technical debt may be deprecated APIs, applications lacking CI/CD (continuous integration and continuous delivery), services with little automated testing, or legacy systems that impact operations.

Regardless of the source, size, and impact, it’s certain that IT teams need to measure, manage, and reduce their technical debt. Equally important is taking steps and instrumenting best practices that help avoid or limit additional technical debt.

[ Also on InfoWorld: Complexity is killing software developers ]

Ruby Raley, a vice president at Axway, believes that reducing and addressing technical debt is more important today because of skill shortages and financial conditions. She says, “The need to reduce technical debt is going to be front and center for CIOs. They will need to find operational efficiencies to fund new projects because of inflation and staffing issues from the Great Resignation and employee burnout. One of these steps will be tech consolidation to reduce maintenance spend.”

I agree with Raley. Although it’s always challenging, development teams must devote sufficient time to reduce technical debt and also take steps to minimize introducing new sources. Agile development teams and organizations that follow devops should review and consider these key practices.

Technical debt prevention practices in development

John Kodumal, CTO and cofounder of LaunchDarkly, says, “Technical debt is inevitable in software development, but you can combat it by being proactive: establishing policy, convention, and processes to amortize the cost of reducing debt over time. This is much healthier than stopping other work and trying to dig out from a mountain of debt.”

Kodumal recommends several practices, such as “establishing an update policy and cadence for third-party dependencies, using workflows and automation to manage the life cycle of feature flags, and establishing service-level objectives.”

To help reduce the likelihood of introducing new technical debt, consider the following best practices:

• Standardize naming conventions, documentation requirements, and reference diagrams.
• Instrument CI/CD and test automation to increase release frequency and improve quality.
• Develop code refactoring as skills and patterns practiced by more developers.
• Define the architecture so developers know where to code data, logic, and experiences.
• Conduct regular code reviews to help developers improve coding practices.

Ravi Duddukuru, chief product officer at DevGraph, believes that software development managers need to work one on one with developers to ingrain best practices. He says, “Developer coaching is key to reducing technical debt. When developers repeat the same mistakes, QA builds workarounds each time. The bad code stays and grows as the developer creates new code.”

He offers this advice, “A good manager will analyze the developer’s code to discover the patterns and work with them to change them, improving this code and all their future code—significantly reducing technical debt.”

Reduce new debt with better planning and estimating

When I asked Andrew Amann, CEO of NineTwoThree Digital Ventures, about reducing and minimizing technical debt, he answered, “The first and most important is proper planning and estimating. The second is to standardize procedures that limit time spent organizing and [allow] more time executing.”

Most development teams want more time to plan, but it may not be obvious to product owners, development managers, or executives how planning helps reduce and minimize technical debt. When developers have time to plan, they often discuss architecture and implementation, and the discussions tend to get into technical details. Product owners and business stakeholders may not understand or be interested in these technical discussions.

So, if you want more time to plan, it’s important to provide leaders with feedback from your planning efforts. Here are my suggestions:

• Schedule collaborative brainstorming sessions with product owners and business stakeholders. Use these sessions to review multiple implementation options and discuss trade-offs, including which options might reduce technical debt and which might introduce maintenance, support, or other forms of debt that require future rework.
• When estimating agile user stories with story points, developers should factor the complexity and effort into the estimate. Stories that create new technical debt should have higher estimates, reflecting the added complexity required to address it later on.
• Identify approaches to measure and manage technical debt so that it’s not an afterthought. Some organizations tag user stories, code, and other artifacts with technical debt and then calculate a tech debt metric. Others define agile principles and governance models so that agile product owners balance their priorities to reduce debt.

By defining a process and establishing metrics, development teams can more easily educate business sponsors about the risks of not addressing technical debt.

Optimize technologies to reduce architectural debts

Last decade’s three-tiered web architectures and SQL databases boxed development teams into a confining structure that didn’t work well for many applications. Today, you can choose from several cloud databases, including SQL, key-value, columnar, graph, or other database architectures. Microservices have several deployment options, including serverless architectures, and developers can build user experiences in no-code, low-code, or one of several JavaScript frameworks.

Selecting too many architectures and development patterns can be a recipe for disaster as it requires considerable development skills and expense to maintain them. But limiting development teams to one-size-fits-all architectures often forces them to build workarounds or compromise user experiences, performance, scalability, or security.

Selecting optimal technologies also requires development teams to brainstorm their implementations. What’s an optimal data model? What level of granularity should developers build into their microservices? How many test scenarios are needed to validate the implementation? When does a customized user experience provide sufficient business value compared to no-code and low-code implementation options?

When teams don’t consider these design considerations, there’s a greater likelihood of introducing technical debt. Minimizing the risks of new tech debt comes down to investing sufficient time to plan, selecting appropriate architectures, implementing devops automations, and evolving development standards.