Technical Debt Assessment:

Every technology project accrues at least some technical debt, defined as “the implied cost of additional rework [to software] caused by choosing an easy solution now instead of using a better approach that would take longer.”  The challenge for each executive is to assess whether or not that technical debt is debilitating. Technical debt is likely at an acceptable level if it only makes each new initiative 10% more difficult. However, it  should be addressed when it makes a new project significantly more difficult, or worse, it prevents new projects from being built or not being proposed at all.

So how do you know if your technical debt is reasonable or debilitating? The following seven questions should guide your technical debt assessment.  

1) Has it become very expensive to make changes to your existing software or worse have you avoided a project entirely?

Some technical debt is manageable, but it becomes prohibitively expensive when it forces you and people reliant on your systems to deal with it the way it is. This stifles business growth and worse yet, your aspirations.  Technology propelling the business should be able  to scale in a timely manner and without increasing risks or operational costs. If this is not feasible, then the technical debt needs to be reduced immediately.

2) Have new technologies emerged since your software was developed?  

Three things happen in the technology sector that lead to technical debt and require refactoring of software and systems: computers get faster, networks get faster and standards evolve. Solutions developed years ago using custom written code may now have standard industry protocols. You may have difficulty communicating with your trading partners or establishing client relationships if your systems predate the standards. These limitations will start to chip away at your business’s relevance in the market.  

3) Have your business requirements changed?

An old system is not inherently bad, as long as the requirements do not change. By way of example, a client of big river had built productive systems that evolved with the client’s growing business over the past two decades. Each day, the firm successfully resolved tens of thousands of transactions, the bulk of which required no human intervention. Each day, however, a few hundred exceptions were resolved by a team in India. With increased global opportunities, the client wanted the ability to triple its business. Rather than continue hiring in India, however, our forward-looking client decided it was the right time to invest in smarter systems. big river reduced technical debt by moving the system to the cloud and improving the client’s back office processes. This saved our client from taking on more operational costs. 

4) Are your systems well documented?

It can be virtually impossible to maintain and enhance code when it is created without proper documentation. If key players are gone, reverse engineering is a good investment. Trying to make enhancements to legacy code without proper documentation is like adding a floor to a building without understanding the foundation. Recently a Global Investment Bank founded in the early 1990s hired big river technologies inc. to help deliver on the back end and front end of a number of its programs. The head of front-end development for the bank described big river’s analysis as follows:

“they produced the best documentation of our system that I have ever seen.”

This means for the entirety of their application’s existence they had been accruing technical debt and it cost more for them to make the needed changes.  Implementing documentation standards will immediately reduce technical debt.

5) When was the last time you brought all key players to the table?

Technology instituted in isolation will result in deep technical debt. This may happen at the bequest of C-Level executive making what they deem to be a simple ask – unaware of how challenging it is to implement technically; or because of an IT person altering a program without understanding the business implications. It will behoove a business to bring these two teams together, in addition to key users, resulting in the most valuable outcomes from the employed technology.

Agile methodologies have revolutionized software development, and Agile’s effects are largely positive. One negative side effect of Agile, however, is that short term decisions can lead to scale issues as volumes grow. Occasional redesign is needed. In financial services (where you never get more than a 3-day weekend to implement new systems), change requires teams of experts who know new technologies, legacy technologies, and your business.

6) Did you have an upfront design phase before making changes to your system?

Organizations can be tempted to ‘save time’ by starting development before or during the design phase. While it seems efficient, the code created often has to be reworked and will cost more money and time later on. A purposeful design phase allows the development team to anticipate risks and bugs before the code is implemented. There are two things to keep in mind during this phase: the user and the desired business outcomes. UX Discovery is about creating frictionless experience for the users. The users in this case could be employees, customers, or both. Business Driven Development keeps the business’s goals and strategy at the forefront of the development process, so the resulting technology brings value to the business and limits the rate technical debt accrues.

7) Who are you hiring?

New code added to your systems is dependent on the functionality of old code.  Interest of technical debt is compounded when refactoring does not happen. Some organizations are in a position where it has almost become impossible to refactor because the people who created it have left or have become too expensive. Companies and systems reliant on COBOL, for instance, can have huge technical debt. Some code has 30 plus years of additions without refactoring. Fewer and fewer people are qualified to touch the code, so technical debt has continued to accumulate. Even companies not reliant on archaic systems can be in danger as they hire less qualified people with little expertise. Often these coders do not keep the future state or business outcomes in mind and eventually their solutions will break.

The good news is there are other alternatives than hiring poorly qualified candidates or losing experts to your competitor who can pay a higher wage. You can build a lasting partnership with a boutique design firm, like big river, run by strategic thinking leaders with deep expertise and decades of experience developing solutions for financial services and entrepreneurial leaders. The knowledge of your systems will be retained organizationally so it will never be lost and you will always employ world-class talent.

Technical debt, even if ignored, does not just go away. The lack of productivity attributed to it will incrementally increase and just like real debt, interest will accrue. It becomes more complex and more expensive to fix bugs and other issues as time goes on. If your organization does not have a plan to acknowledge and address technical debt, your ability to respond and compete can be extremely curtailed.

If we at big river can help you assess and address your technical debt, please do not hesitate to reach out.

Click here to start the conversation.

or subscribe to our mailing list.