In an ideal world, developers would design apps, software, and new systems from the ground up on the foundations of best practice. Well-designed code that makes it easy for future iterations to be implemented will also enable a business to be more agile and innovative.
However, the corporate world is ruled by strict deliverables, budgets, and deadlines. Whether it’s implementing a new solution or maintaining a legacy system, poor decisions and shortcuts are often taken to save time and money. Those that protest that these moves are counterproductive will be told to “just do it.” Welcome to the world of technical debt.
The metaphor of technical debt (TD) was first used in 1992 by Ward Cunningham, who found that poor code dramatically reduces productivity over time. He also warned that although the team does not build up the technical debt, it still rises involuntarily.
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
Ward Cunningham
The early warning signs of technical debt in your business
It often begins with tweaking code to offer a quick fix or get a project over the line and will quickly prevent you from scaling in the future. Time constraints, budgets, and demands from the business are often blamed for the need to compromise. But workarounds, rushed incremental changes, and postponed decisions will quickly create unnecessary complexity that accumulates in your technology stack.
Fast forward a few years, and business leaders quickly find themselves investing more time, money, and other resources trying to pay off the technical debt that they unwittingly created. Much to their chagrin, leadership teams are faced with the reality that poorly written code will create a technical debt that can last for decades.
As new features are added on top of poorly written code, it will also invite more bugs into the system. As the technical debt continues to build, your productivity grinds to a halt, and output will become much slower, causing low morale within a team. Does this story sound familiar?
The real price of technical debt
Every project and its requirements will evolve and require last-minute changes or modifications. What typically begins as a series of uninformed decisions will quickly generate additional costs. The problems arise when tech teams are forced to revisit legacy systems that have been implemented and need to be managed accordingly.
Project teams will naturally move onto the next value-add project, and the technical debt is left unpaid accumulating interest. Decision-makers need to be reminded that the value the project go-live will deliver today will also involve the cost of fixing the technology in the future.
Over time, an application might take longer to load and damage the user experience. There is no escaping the fact that the debt will need to be paid at some point. Rushing out bad code and writing it off as technical debt, that you will come back and fix later is also a dangerous game to play. Why would you choose to gamble on your business running efficiently, effectively, and securely?
The real costs of maintaining and building on top of old software solutions are not just financial. As people leave the business, you will have a new team that will inherit these problems. Traditionally, they will struggle to understand the original design and comprehend why poor decisions were made. It can also stop innovation in its tracks as developers focus their efforts on firefighting issues rather than adding value to the business.
Not all technical debt is bad
Technical debt doesn’t have to be bad for business. Just like a financial loan, it can enable you to achieve your goals faster. The problems only surface with the absence of a plan that will address your technical debt later. Just like in your personal life, failing to make your payments will sow the seeds of future problems.
It’s arguably not the debt that is the issue, it’s a failure to manage it that’s the problem. In the business world, the cost of technical debt can involve the sacrificing of flexibility, agility, scalability, security, and ability to innovate. Everything your project or digital transformation initiative set out to achieve will be undone by not managing your technical debt properly.
As you stand at the crossroads, you have two choices. Do you take the faster and easier route that will get you where you need to be, but at a cost? Or do you play the long game and take the harder way with best practice code and design? The reality is that both are valid options, but you need to be aware that each path will come with a different technical debt.
As an idealist, I like to think our time would be better spent avoiding technical debt entirely by doing things right the first time. Deliberately writing lousy code to make a deadline doesn’t sit well with me. But as a realist, I know that it doesn’t matter if you fix the code today, tomorrow, or five years from now. The reality is your technical debt will still need to be paid in full, and there is no escaping your responsibilities.
I’ve been involved with modernizing the “technical debt” of several corporate and government clients. What they all had in common was essentially a succession problem. As older workers retired or neared retirement the debt was unmanagable by new employees. People who understood why code was done a certain way were gone, it made no sense to someone new and ultimatley wasn’t relevant anymore.
Ultimately everything was built over from scratch in eah of these instances. The same output was produced in a fraction of the time. While initially the old timers were concerned the efficiency would result in them losing their job they ultimately found they were free to do the value added work they actually wanted to do rather than the mundane, time consuming tasks. I would urge businesses and agencies to think about the issue of technical debt before getting to the breaking point.