Chances are if you work within a business or have your own business you have come to understand that technology is an integral part of your company’s growth. You’ve implemented technologies in multiple ways using pre-packaged software and hardware, custom applications, websites and either on-premise servers or cloud services. It’s difficult to get by in today’s business without the implementation of technology products and services in some form or fashion.
For over 15 years as an engineer, I’ve seen many implementations of technology at businesses big and small. One problem that I find rearing its head consistently is the unforeseen problems known as technical debt or tech debt for short. Most businesses don’t expect it, and most engineers don’t plan for it. With the speed to which businesses implement technologies, it’s just something that happens, and without proper planning and foresight, it will present problems with your business efficiency and effectiveness. More importantly, it creates a direct impact on the bottom line. To understand what is tech debt and what problems arise from it, we’ll explore the definition, the risks and what to do to mitigate the risks of technical debt.
What is Technical Debt?
Technical debt is a metaphor that conceptualizes the tradeoff between short-term and long-term value. This is defined by the [Software Engineering Institute at Carnegie Mellon University](http://www.sei.
Time and budget constraints are the leading cause of technical debt. It produces behaviors that lead to “Cutting Corners” sacrificing performance and scalability for speed and reduced costs. There are several ways engineers introduce tech debt into a piece of technology, and I’ve identified three areas that bring about technical debt.
A common occurrence that leads to technical debt is miscommunication. To carry out the vision of a business with technology requires a clear understanding of business goals, and how the technology can achieve those goals. Without a clear understanding, the team in charge of carrying out the technology needs of the business can introduce technical debt by making uninformed decisions.
For example, a marketing team may request to capture visitors on the company website using a registration form. However, the business goal is to capture visitors on the company website to see traffic patterns and visitor interests. Without the detailed requirement, a simple registration form is created and deployed only to capture that a user arrived at the website. However, the more descriptive request will involve a registration form, tagging, visitor history, page views, etc., so that behavioral patterns can be tracked and reported.
The example shows that a far more involved process and technical feet can be sacrificed by simply leaving out the detailed business goals. This sacrifice leads to technical debt, requiring a revisit and re-architecture to meet the true goal of the business.
Another occurrence of technical debt is implementing technologies without the knowledge or skills required to meet requirements. This is a tough assessment because the team responsible for carrying out the company’s technology needs has to admit to not knowing everything. As an engineer, I can attest to many instances where I didn’t want to come to grips that I didn’t know everything. It happens, and after running several engineering teams in my career this is not uncommon.
This behavior introduces technical debt in the most unintended ways. Let’s say an internal IT team is tasked with building a piece of software for the company. The budget has significant limitations and the deadline is fairly short. The team is only familiar with a specific technology, and due to the constraints of time and budget, they cannot introduce a new technology to build the software. Therefore, they fit what they know into the software they are building rather than use the right technology. They introduce workarounds, hacks and other methods to fit what they know into the technology they are building. Once completed, it works until one of your integration partners performs an update that breaks one of the workarounds. The software has to be revisited and then updated because of your partner’s update.
This scenario is an on-going example of technical debt. You’ll incur the cost of revisiting the software on every update in order to keep it working when the right implementation would resolve the issue long-term. Bottom-line, if you have to “hack” technology or build a “workaround”, chances are it is technical debt.
Lastly, an occurrence seen far too often is as simple as an engineer that performs a lazy implementation of technology. Whether a lack of experience or motivation, far too often some engineers just build technology to work using what’s called, “The Happy Path.”
The Happy Path is simply the use of technology exactly as required or intended. For instance, I fill out a registration form with all required fields in the appropriate formats on a piece of software, and I submit. Done! It works! That is the “Happy Path.” However, the reality is that the path is rarely happy. Some fields will be missing, filled out incorrectly and in some cases, will include submitted characters that may cause security flaws. Once deployed, it’ll usually come in the form of security holes or a software bug. At the end of the day, it falls under technical debt.
I would like to say that I haven’t seen this in a while, but just recently I came across a piece of software where the engineer decided to simplify his/her life by accidentally exposing encrypted passwords on the side of the technology that is the most vulnerable to cyber attacks. It required the business to pay additionally for the re-writing of that piece of software to eliminate the vulnerability. It’s the true definition of technical debt and one that is hard to identify without some assistance from an outside consultant or adviser.
Effects on Business
As you can see, technical debt has adverse effects on your business because of additional costs incurred to revisit technology that was already implemented. Whether it’s a third party, external technology or internal technology, the cost is similar. You get a certain value of the technology today, but at a cost of fixing the technology in the future.
The most obvious display of technical debt is one that is externally facing to your end-user or customers. This is one that is visible and affects user experience. A prime example is an application that has a long load time. It isn’t a breaking issue as the application continues to work, but it is still visible and has negative implications on the user experience.
Internal technical debt, however, isn’t visible to the end-user. An example is when a piece of software makes three calls to a database, and the engineering team realizes they can accomplish the same result with one call to a database. It will not be noticed by the end-user but will improve the application slightly. It may or may not be revisited, but is still considered tech debt since there is a value to revisiting the issue.
How to Mitigate Risks of Tech Debt?
The risks of technical debt extend beyond the difference between the short-term and long-term value you receive from technology. The deeper risks lie in keeping your business running efficiently, effectively and securely. You must mitigate these risks by having effective communications between your business team and your IT team, a team with a breadth of knowledge and experience in multiple technological areas and a team that has an intrinsic pride in what they deliver to your business.
Effectively communicating the mission and vision of your business to the IT team is vital to minimizing technical debt in this area. Having someone with the ability to translate the business needs to the technology needs of your company can help bridge the gaps leading to missing requirements and subsequent technical debt as well. This person can come from your organization or your vendor and can come in the form of a project manager and/or business analyst.
Having access to a team with a breadth of technical knowledge in several technologies and their implementations is another way of mitigating technical debt. You should investigate the need for an information technology consultant that can take an objective look at your technology needs and overlook the implementation of technologies to ensure that they will meet your business objectives and goals minimizing the appearance of technical debt.
Intrinsically Motivated Team
Additionally, finding the right talent that is intrinsically motivated in building technology for your business can ensure the success of technological implementations and minimizing technical debt. Whether internal staff or external vendor, having someone that is motivated by your success will give you the best opportunity to minimize the risks of technical debt.
Time and Budget
Lastly, the most important way to mitigate the risks of technical debt is to ensure that you have the appropriate timeline and budget. As the [Software Engineering Institute at Carnegie Mellon University](http://www.sei.
It is no secret that there is plenty of technology available out in the industry and their purpose is to increase efficiency, reduce costs and increase the overall profitability of your business. However, the inability to manage technical debt effectively can turn technology against its very purpose and hurt your business in the long run.