To release products faster and pursue market opportunities, it’s crucial that dev teams find a way to reduce the drag of technical debt -and that’s what this blog is about.

It’s hard to move fast when you’re dragging a dead weight behind you. In a business culture that demands agility and speed, technical debt is a serious liability that must be eliminated.
Every software engineer knows, in the back of their mind, that technical debt is a bad thing to have looming over their next release. Product owners and business stakeholders can sometimes push this problem out of the eye line. They have more global concerns to manage, like deadlines, business goals, client satisfaction, and other outcomes.

What’s a little bit of badly-structured code if you’re meeting accelerated delivery schedules?

Eventually, however, focusing solely on the MVP and not the longevity of the product will catch up. Messy code will make it hard to improve the product. Its lack of modularity will make an agonizing mess of incorporating new features later on. And, after the user feedback starts rolling in, it will become increasingly difficult to respond quickly, or at all!

There’s always a balance to be maintained between deadline pressure and long-term sustainability but at some point, you’ll need to “stop the madness” and start tackling that mountain of technical debt. This blog is about the “how”?

The first step is realizing you have a problem.

I’m not trying to imply anything here, but perhaps it’s helpful to borrow an idea from psychologists for a moment. The first step to overcoming a problem is to admit you have the problem.

Team members, here are your manifestos:

Programmers

There are a zillion reasons why you’ve had to create sloppy code but let’s face facts: these factors don’t ever go away. Your unmanageable codebase is the Frankenstein monster patched up with all the shortcuts, workarounds, and band-aid approaches to product development that have allowed you to meet your project goals and keep the PM happy.

But you know, in your heart, that the ghosts of bad architecture and sloppy code will be back to haunt you.

Product managers:

Yes, cleaning up the code in your product means allocating resources that could otherwise be “productively deployed”to meet deadlines, business goals, and other top-level concerns that you have.

I agree -that’s hard to do because the “just ship it!” mentality is what has allowed you to ship on time, come in on budget, and keep things moving forward. But while these are justifiable reasons for allowing poor development practices to occur under your nose, it’s time to find a way to start paying that debt. Admit there’s a problem and let’s start working toward a solution

Yes -it’s time. Let’s set up a realistic plan for addressing technical debt.

Now that you’ve agreed there’s a problem, and the whole team is on board, here’s what to do next.

Step Two: Address Technical Debt at the PM/Planning Level

Paring down your technical debt isn’t just about getting in there and cleaning up the code or fixing the architecture. It’s also about what happens at the conference table when you’re meeting with the product owner. Here’s the most important action the BA or PM can take:

Bake in time in the schedule for addressing technical debt. That can be set out in several ways:

• Calculate the amount of bandwidth you waste due to technical debt and communicate that.
• Help the product owner see that by addressing technical debt now, you can begin to focus on long-term productivity
• Include time in the agreement for running static code analysis to chart your progress
• Plan to dedicate some iterations to addressing technical debt
• Include time for refactoring

Step Three: In Dev!

Be Proactive with Testing

Engineers, I know you are aware of all the Best Practices, especially where testing is concerned. I also know that those Best Practices fly right out the window when deadlines loom. The (valid) strategy of launching a minimum viable product (MVP) to reduce time to market works well -until it doesn’t! Eventually, you’ll have to get under the hood and fix the code or transform the architecture to ensure your product stays standing. And, for a product-in-use, that may be like changing the engine of a jetliner full of passengers -while it’s in mid-flight!

Here’s what you can do when you’re developing a new product.

• Write unit tests for everything
• Target increased code coverage
• Understand that test automation can have indirect, positive effects on technical debt, even if you don’t see a direct impact. You’ll need automated testing for the typical project.

Address Technical Debt at the Code Level

Finally, developers can begin to whittle down the technical debt at the foundational level of the product: the actual code. Here’s a short list of suggestions:

• Pay attention to coding standards
• Don’t compromise on code reviews
• Focus on transparency
• Practice “opportunistic factoring”
• Include technical debt considerations in your Definition of Done
• Communicate tips & Collaborate with other developers on preventing technical debt

Wrap-Up

Of course, I know your dilemma — I’ve done product developmentand have been a product owner myself. I know the pressures that for a business to compete, thrive, and move forward. So yes, I too have slappedband-aid code into a product just to ship on time. But at some point, that forward motion will come to a slow, painful halt when the inefficiencies of these sloppy practices come home to roost. Iterations become painstakingly difficult. Adding new features is a nightmare. And just forget about experimentation and new ideas. As a business owner, a PM or a coder, is that what you really want? I want to talk more about specific ideas, tips, and techniques to address technical debt -so do stay tuned. And tell me -what has worked for you?