What is technical debt?Â
This is the metaphor devs use for bad code. This is an OK definition, but a better explanation is code that don’t model the problem we’re trying to solve. Even with expert implementation, our businesses and products evolve. The code modeling them them must keep up. Keeping an existing solution too long is like shoveling snow from your driveway with the same shovel you used to dig out the garden last spring. We know the best way to keep your driveway clear for the winter.  But we can’t justify a trip to the hardware store when your focus is on how much snow can be removed in the next 30 minutes.
Experienced developers know how to keep the code in a workable state, but we talk about technical debt in the wrong ways. We think equating bad code with debt will send shivers up the business owners spine. We are surprised when they aren’t worried by it. We shouldn’t be. Debt isn’t inherently bad. It is ironic when the most strident opponent of technical debt wouldn’t think twice about taking out a home or car loan. For a business owner, debt isn’t something to fear, it’s something to manage. Taking out a loan can help you invest and grow your business. Even a pay-your-card-every-month person like me jumpstarted his iOS development by putting my first Mac on a credit card.
So technical debt is good? What’s the problem?
It’s true, your users don’t care what is happening under the hood. But like the credit card you maxed out on vacation, technical debt will drive your business into the ground by making it hard to advance your product. Tech debt builds on itself like a payday loan. If unmanaged, it WILL effect your ability to innovate and stay ahead of your competition. That quick fix you thought was a no pressure loan from your Uncle will transform into a toxic mortgage that uses up all your development budget without producing anything of value.
How can I recognize technical debt?Â
Unfortunately, this debt doesn’t appear on a balance sheet. The best people to ask are your dev team but some teams don’t know the difference or are too invested in the current solution. Here are some warning signs to look out for:
Simple features take a longer time to implement than estimated. “This would be a quick fix if…†is a common phrase heard in projects with a lot of technical debt.
You can’t add a feature without breaking something else. New features spend a lot of time in QA because changes in functionality break other parts of the codebase.
Parts of the codebase no one is willing to touch. This is common effect of a lone-coder working on a codebase for a long time.
What are some sources of technical debt?
Inexperienced developers. Writing software the right way takes experience, which largely consists of writing software the wrong way and dealing with the consequences. Does your team have people on the right side of that curve?
Aggressive deadlines. Even with experienced devs, writing a complete solution may take more time than your business can afford.
Rapidly changing requirements. Turning a large ship around takes time. We can make quick adjustments, but they can have long term consequences.
Evolving business and platform changes. This is inevitable. The initial investment to write the app is only a down payment. Upkeep and maintenance make up a large part of the software budget and need to be planned for. You wouldn’t expect to buy a car without budgeting for oil changes and maintenance.
How can I manage tech debt?
Work with experienced devs, or devs that can oversee the junior developers work. Ask what parts of the solution should be changed. Your team will be thrilled.
Make sure more than one person understands every area of your codebase. Even seasoned developers can use a second opinion about an approach to a problem. Be wary of the ones that don’t want input from others. The worst code bases I’ve seen are often the result of a lone coder working for years without oversight.
Don’t keep putting off tech debt payments until after the next release. That day will never come. Payments should be continuous and ongoing. Instruct your team to leave the code in a better position than when they found it. Find devs that understand HOW good code should look and can make it happen efficiently.
Unit tests. Tests are a great reminder to keep your dev team making continuous payments. If code is hard to test, it’s hard – and expensive – to change.
tl;dr
Technical Debt becomes a problem when you spend more energy paying it off than adding value to your company. This will happen sooner than you realize unless it’s actively managed. Short term technical debt is fine if it moves your business forward. But keep on top of the payments.
This is part of a series to help entrepreneurs and business owners make the best use of their development budget. See more entries here.
Also published on Medium.
[…] to your users to justify the cost of including them. Building the wrong features hurts your app and your company. It’s better to build your app with a focused […]
[…] This maintenance has a cost. If the code was written cleanly, this cost can be low. If it was written poorly the cost will be high (sometimes extremely high). Maintaining the current code most often becomes an issue when adding new functionality. The developer has to add the new code while also keeping the old code working. If the code is in an unrelated system, the cost is usually marginal. But if the new functionality involves the same systems, this cost can be high. An experienced developer knows how to keep a software system in a condition that can be changed without massive maintenance costs. But no developer can turn an economy car into a school bus. […]
[…] if you can find someone to work for free, it’s easy to add code that removes value from your software. And even with a top-quality development team, delivering the wrong software […]