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. Maybe using pre-packaged software and hardware, custom applications, websites or either on-premise servers or cloud services. It’s difficult to get by in today’s business without the implementation of technology products 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. 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. The main questions you may be wondering are technical debt is, and what problems arise from it. We will 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. The [Software Engineering Institute at Carnegie Mellon University](http://www.sei.
Adverse Behaviors
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 technical debt into a piece of technology, and I’ve identified three specific areas.
Miscommunication
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. As well as, how the technology can achieve those goals. Without a clear understanding, the development team in charge of carrying out the technology needs of the business. Which 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. However, more descriptive requests involve a registration form, tagging, visitor history, etc., so that behavioral patterns can be tracked.
The example shows that a more involved process 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.
Technical Limitations
Another occurrence of technical debt is implementing technologies without the knowledge or skills required to meet requirements. This assessment is extremely tough. This is because the team responsible for carrying out the company’s technology needs admit they don’t know everything. As an engineer, I can attest to many instances where I didn’t want to acknowledge 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. Tasking an internal IT team with building a piece of software for the company may be a cause. The budget has significant limitations and the deadline is short. The team is only familiar with a specific technology. So, 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. Revisiting and then updating the software is a must because of 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.
Bad Behavior
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. Additional costs to revisit technology are incurred because it 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. 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. The end-user will not be notice, but will improve the application slightly. It is still technical debt since revisiting the issue can add value.
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.
Effective Communications
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.
Knowledgeable Team
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, 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, motivating others to have 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.