A Complete Guide to Technical Debt

As an investor, technical debt can seem overwhelming and unstoppable.

And in a way it is.

What is technical debt?

Technical debt is a combination of five internal and external factors that can eventually add up to make even the easiest tasks hard to do, resulting in costly, unpredictable software development efforts. Let’s walk through them, one by one.

Outdated technology. 

Tech moves fast, and eventually the third-party tools and technology that you used to build your system will no longer be supported, meaning you’ll have to migrate to newer technology — which costs plenty of time and money. Some examples that come to mind: the rise and rapid fall of Microsoft Silverlight, Adobe Flash, and others.

A tangled web of quick code fixes.

In a high-pressure scenario where something critical is broken and needs to be fixed yesterday, developers are often forced to take shortcuts and create temporary solutions. Soon, those messy fixes necessitate more fixes, often with poorer and poorer quality, and eventually the code can’t be salvaged.

Outgrown software architecture. 

Sometimes, a system that’s originally designed as a prototype or a minimum viable product (MVP) is asked to handle a much larger-scale workload than it was intended to handle. Essentially, there’s a big difference between how code is layered and structured for a small system with a few hundred users vs. an enterprise system used by thousands (or even millions). 

Aging source code. 

Because coding is a learning process, source code is often written at a lower proficiency level — meaning the earliest code in any developer’s career will likely be his/her most inefficient and potentially full of bugs. Software architecture and development is an ever-learning endeavor. And truly, if your software engineer doesn’t look at yesterday’s code and feel it could be better, you may want to find someone who does.

Undisciplined development practices. 

When a development team is disciplined, you shouldn’t be able to tell who coded what within a software system because it’s written so consistently that one developer could easily take over the work of another. But when a team lacks discipline, the quality of code suffers because the efforts are uncoordinated or rushed. And just to dispel one of the greatest myths in software development: Being agile isn’t the same as being disciplined. 

And while investors recognize tech debt as an inhibitor to their ROI, developers recognize it as something much more sinister. Technical debt in software development is a very real thing – something that can cripple their team if left unchecked (much in the same way personal debt can devastate a person’s household).

The maintenance issues they tend to ignore or put off because they’re either too hard to address, or they’d rather be working on new features, are invariably made worse by last minute “quick fixes.”

Even worse, the amount of time spent addressing those issues counts as interest on your technical debt. And if left unchecked or untreated, those issues can spiral out of control and morph into something truly awful … negative development velocity. Yep, you really can end up in a situation where every day is worse than the next.

So, round and round you go on the hamster wheel, month after month, watching your technical debt quietly pile up as you struggle to keep the lights on and your customers happy.

Is technical debt always bad?  

No! If you think and act strategically, you can actually turn it into a competitive advantage, and leverage it for growth and real ROI.

It’s important to understand that it’s not the debt itself that kills you. It’s how much you have to pay to service it. Refinancing your technical debt at a much lower interest rate is possible.

To do this, you need to have an honest discussion with your team (and by “team” I mean developers, CEO, investors, everyone and anyone who has skin in the game) to determine what needs to be done to grow the business and why.

Then, do a little digging and see which resources, sub-systems, or components you have that can be reused. Reusability is a savvy way to eliminate portions of your technical debt.

How to reduce technical debt?

Prioritizing reusability reduces technical debt because it eliminates the need to reinvent the wheel every time a new project comes up. If you can, build your own vertical platform (consisting of your own reusable components) to assemble any number of new products you want to offer the marketplace.

Just think of how much faster you can launch new products when you can re-use components you’ve already built as a part of other applications!

And this, my friend, is how technical debt is paid down.

As it stands, most organizations are paying insanely high-interest rates on their tech debt.

Real Life Example of Technical Debt Solution – LiveEdit Case Study

LiveEdit, a software company that offers website building and online scheduling tools, called us in recently to help get their R&D budget under control.

Overall, they had some serious challenges. They were struggling to configure their R&D teams to improve productivity and stay competitive.

Plus, they were spending about 80% of their R&D budget on maintenance alone.  Put another way, servicing their technical debt was consuming 80% of their total R&D budget.

PlatformPlusTM enabled LiveEdit to use existing code while also implementing a flexible, modern architecture that is wholly managed by experienced R&D leaders. This allowed the LiveEdit team to dramatically reduce their R&D spend on maintenance from 80% down to 20%, giving them bandwidth to focus on revenue-generating innovation instead.

LiveEdit has since experienced phenomenal night-and-day differences in terms of hitting deadlines, staying on budget, and being proactive with customer issues that may crop up. Plus:

• Their time spent by leadership on managing R&D was cut in half
• They entered a new market with an innovative solution
• The team developed a new product for an existing partner, earning a Partner of the Year designation

With help from Modularis, LiveEdit was able to pivot its business and diversify its portfolio to take advantage of new market opportunities. And remember how they spent 80% of their R&D budget on maintenance?

It’s now down to just 20%.

How to solve technical debt?

The secret to solving technical debt lies in paying it back at the same time your development team is delivering value. Now, I’m not saying you should authorize a yearlong project to port your existing functionality to the latest version of Angular; doing that — or rebuilding it from zero without adding value to your customers — is a lose-lose situation: You lose time and money without developing new features, and your customers receive zero value from the effort. 

But there are three recommendations to attack your tech debt problem that allow you to address it efficiently.

Get the requirements right!

When you’re planning your next product release, make sure to understand the value you’re aiming to deliver with new features — and that it’s worth fixing bugs or tech debt standing in your way. You’d be surprised how much less complicated your features will be once you find the root of the problem (and solve it).

A great first step to understanding new feature requirements is to reframe the problem you’re hoping to fix and see if there’s something missing. It’s possible you’re trying to solve the wrong type of problem. In my experience, there’s usually some larger overarching driver for requesting new features. 

Consider the following scenario: A customer comes to you for a widget — a blue widget. Your dev team springs into action, and everyone’s happy because they’re all on the same page… until about a week later when the customer calls to say, ever so nicely, that they need the widget to also come in red and yellow. And before you can tell him that doing so would require more time and money, he tells you the deadline is the same, and so is the budget.

So, you inform your dev team of the change (and duck behind a desk to avoid the objects thrown at you). It’s at this moment you realize what your customer really wanted wasn’t a blue widget, but a widget where you can customize colors.

This is how technical debt begins to snowball. 

The root of the issue? You’re solving the wrong problems for your clients. You focused too much on the what of the request and not enough on the why. 

The reason they asked for a widget was to solve a problem for their business and/or create new value for their customers. Something wasn’t working right, or it wasn’t a smooth experience, or maybe they just want to improve ease of use. At the end of the day, they needed value.

If you don’t understand where your solution fits in your customer’s revenue generation engine, you’ll find yourself constantly working on the thing your customer communicates, not on the thing they need to preserve or create revenue. 

That’s why the first questions you should ask are: 

• What is the real problem they’re encountering?
• Why do they want to solve that problem?
• How can we incorporate this request into our solution and make it valuable for others?

These questions can help you better understand your client’s needs and ensure you’re putting more energy into creating value (and paying technical debt along the way).

Make sure what you’re building is focused on generating revenue

You need to start thinking about the bigger problems your customer is facing and embracing an environment where your dev team is looking at their projects in business terms. How do our R&D efforts add more value to the software we sell? Is there an opportunity to solve a customer or prospect’s problem and use that effort to charge more or secure your revenue stream?

How can you, as a software leader, give your dev team the broader strategy you’re executing? Making sure your product roadmap aligns to key performance indicators (including revenue and customer retention) is imperative to reducing technical debt. How are the product roadmap and KPIs of all software companies connected? 

Well, if your sales and marketing teams are executing a business strategy to bring on $10M in new revenue and your dev team isn’t aware that there will soon be a large influx of new customers, then they may build features or make infrastructure decisions that impact their ability to scale the software to new customers quickly. This creates a need for future development that may cost time, money, and even unsatisfied customers because you cannot ensure the same quality of uptime or service. 

By unifying your dev team and sales team around common goals, you are preventing R&D or sales decisions from impacting the other. Just help your dev team look at the longer-term impact of their decisions so you can close deals now and into the future.

A couple of questions to ask yourself here are:

• How are we generating revenue today?
• How do we want to generate revenue in the future?
• How will we calculate our ROI on our R&D developments?
• How do specific customer requests fit with our overall strategy?

By stopping to think through these questions with your sales team and dev team, you’ll have less technical debt and more value for customers and prospects.

And, that leads us to our final recommendation.

Team discipline in software development

A lot has been written about agile development and the adoption of lean manufacturing principles in software development. However, we’re missing the mark on what all of this is done in the actual software development practice.

Let’s see if this sounds familiar. You’re frustrated at your software team’s inability to deliver on time and within budget again. Your development costs are three times or more over the initial estimate, and you feel you don’t have control and the necessary knowledge to make decisions. You ask your team for a firm delivery date and they respond that it’s a matter of days or weeks… and they fail to deliver again.

You ask your team for solutions, and invariably you get one of these responses:

• We need agile training and to get certified in Scrum/SAFe/(insert a methodology here)
• We need a scrum master/project manager/(insert a manager role here)
• We have too much technical debt and need to rebuild our system from the ground up with LAMP/MEAN/(Insert the newest technology here)

All of these are valid responses. However, none of these are going to fix your real problem. Having daily standups will improve communication, bringing in a scrum master or project manager will improve project visibility, and building everything from the ground up may not be financially viable.

In my experience, when there is so much technical debt accumulated, the problem is due to the lack of discipline when coding because most plans omit the biggest risks in any project: steep technology learning curves, project setup work, existing customer upgrade work, and unplanned support work outside of the project. 

All these overlooked tasks can result in more than a 3x variation between the original estimate and the reality of the project. With these odds, your project is doomed from the start, the time pressure becomes unbearable as the project progresses, and your developers start taking more risks to try to deliver on time. Therefore, the technology debt cycle is perpetuated: You pay for some of it, but you acquire plenty more.

Your development team must be more disciplined when estimating a new project. It needs to resist the urge to make technical decisions without considering the business impact. There is a time and place to learn how to use the latest and greatest technology, but you should avoid doing so when the risk for delivering a keystone project is already high. 

This is where sharing your vision is imperative; you should provide your development team a clear understanding of the criticality of your ask. Set the right tone at the beginning of your project to guide the team on what they should do and what they should avoid doing.

How to avoid technical debt?

Technical debt is unavoidable, and it comes with a very real price tag. It feeds like a virus, growing bigger and more intrusive right under your nose because of things like: 

• Additional developer time to manage new features or capabilities
• More manpower to maintain existing systems
• Financial loss due to security breaches
• Lost sales from system outages

Make no mistake: Technical debt is a real cost of doing business, and if left unchecked, it can crater your budget and productivity for years to come. Savvy CEOs know this and will have processes in place to keep it in check. 

Some expert thoughts

Spend more of your time focused on selling. 

By fortifying your team with PlatformPlusTM, you can delegate the mundane, day to day tasks within research and product development consuming so much of your time.

Build in Systems of Engagement to expand your on-premise software products with multi-tenant SaaS apps. 

By allocating budget towards modern experiences like mobile apps, web portals, dashboards, and even RESTful APIs, your investment in R&D will generate net new recurring revenue as you spend more time innovating and modernizing.

Give your customers what they’ve been asking for. 

Before you could only spend 20% of your R&D budget delivering value to your customers. Now you can spend 80% doing just that. If you take the incremental approach I’ve described above rather than bet everything on a “next gen” product that is years from being done, you can give your customers what they’ve been asking for, expand your footprint within current customers, and start lighting up new customers as you unleash your team’s ability to innovate. 

It’s amazing what you can do by refinancing your technical debt and flipping your current R&D spending on its head.

And it all starts with the right partner, the right platform, and the right leadership. You get it all with PlatformPlusTM.

Make no mistake, technical debt is unavoidable and comes with a very real price tag. It feeds like a virus, growing bigger and more intrusive right under your nose. But with a trusted partner like Modularis working in lock step with your team, you can quickly drop the interest you pay on that debt, work down the principal over time, and get back to what you love most: writing invoices.

If you need help evaluating your technical debt and finding a path forward, send us a note and we’ll give you a personalized recommendation that’s right for you.