As a leader in charge of a departmental or project budget, there is a term to be familiar with that may have slipped through the cracks. As software development projects continue moving forward and evolving, what are the hidden costs?

What is Technical Debt?

Technical debt is the term given to leftover costs associated to defects and other plot twists that remain unresolved at the end of a development project.  This concept reflects the implied cost of corrective rework that results in selecting a fast and easy solution to meet a time deadline, instead of identifying and implementing a complete solution.

In other words, “Code it quick and get it out the door.” It looks good on a project timeline, but in the long term, may require more maintenance costs and risk a lower user satisfaction.

This reminds me of an old slogan, “You can pay me now, or you can pay me later.” This was a marketing campaign from Fram oil filters back in 1970, and the phrase can still be applied in many scenarios today. Their message was that you could pay a little for an oil change and new filter now or a lot for an engine rebuild later. The idea behind the slogan still holds true today, especially for IT. Think of it this way. You can pay a little now to meet a deadline, but at what cost later? Let’s consider those potential costs for a moment:

• Rework to analyze and correct the defect later
• Workarounds that slow productivity of the stakeholders
• Loss of function until the issue is corrected
• Loss of revenue potential
• Loss of customers due to defects being visible
• Downstream dependencies leading to additional dysfunction of systems

Thinking of these negative impacts is enough to make any project sponsor or champion pull the reins and challenge the Project Manager (PM) when they say, “There are some tiny defects that we won’t address in the name of the project timeline.” While a PM may be thinking of the immediate costs and deadline, they are not measuring the detriment of ongoing debt. Before signing off, be sure complete awareness is present of the ongoing implications. Eyes wide open is the key to managing technical debt effectively.

What does Technical Debt look like?

Let’s take an example of a developer working on a project. Some of the code expands to several pages with many identical elements. The quickest way to replicate that code is to copy and paste some HTML for each of the pages. At first, everything goes beautifully and everyone is pleased.

The debt payment happens when an update is made. The change now needs to be updated in all of those copy and pasted places. A lower debt solution would be to use a tool like React or Angular to apply these updates automatically. They create design templates in which any changes or updates in one place will correct all of those in similar sections. The cost of utilizing templates requires more expensive resources to develop and takes more time up-front. However, the payoff is quicker turn-around in applying changes and fewer mistakes.

At Lighthouse, we were asked to analyze and make recommendations to improve the quality of a client’s customized point of sale (POS) system.  We ran our code analyzer on the system and identified hundreds of software modules that were so complex that they were virtually untestable.  But, we also identified thousands of lines of code that were completely duplicated in the code base.  It was so pervasive that it prompted us to enhance our code analysis tool to look for these fully duplicated modules and for those that were mostly duplicated (ex. they might have been slightly modified to add another parameter, but otherwise were 100% duplicated.)  It was a technical debt mess!

Let’s take a moment to explore and categorize the different types of technical debt.

Planned debt

Planned debt may be strategic in nature from the very beginning. This may be from a project developing a prototype or pilot. Part of implementation is that it’s completely understood and agreed on that it’s a test run from the very start. Following implementation, feedback and reporting are collected on the functionality of the test product. Along with feedback, suggestions for improvements are collected with the identification of defects.

Planned technical debt is an expected loss, but a loss to be controlled and accounted for. Good record keeping is key to tracking all expenses and decisions (including rationale) ranging from development expenses to customer satisfaction ratings.

Unintentional debt

Herein lies the human factor, otherwise known as the defects. Our first thought of unintentional debt exists in the form of defects being the result of human error, poor workmanship, or lack of knowledge. System updates may also cause havoc on certain code, creating downstream functionality or security risks. Test automation may be used to identify these risks as fast as the code is written, so that they may be addressed immediately.

Unintentional debt is not limited only to defects. Additional sources of unintentional debt may go back as early as poorly defined or heavily changing user requirements.  Fairly often, a weak system architecture and/or poor database design can create dramatic increases in technical debt.  Before agreeing to any changes to a project and its deliverables, the PM should be ready to talk about the potential downstream effect prior to gaining approval.

Unavoidable debt

This debt is the result of something that may be unplanned, but cannot be avoided. Some examples may be updated regulations, changes in dependencies outside of the project (systems or hardware), or new mandatory requirements being introduced mid-project. When these occur, some negotiation of the time, cost, resources, or features originally agreed upon may be in order.

Controlling technical debt

The key to controlling technical debt is complete clarity and transparency when it presents itself. With that transparency, thoughtful negotiation and decisions can then be made on how to address the technical debt.

Debt-managing tips:

• Challenge the team to think beyond the project to identify the ongoing impact.
• Automate testing wherever possible, especially with repetitive tasks, to be sure of a perfect execution every time.
• Monitor the team’s rate of progress. Investigate a slow-down, which may be a key indicator of technical debt presenting itself.
• Monitor complexity because with high complexity, developers are more likely to break something while they are trying to fix something else.
• Ensure the system architecture and database are designed knowing that the system functionality will expand over time
• Manage, monitor and report defects, time to investigate and complete, test effectiveness, and frequency.
• Maintain code test coverage. The target range of well written tests is 70 – 95 percent of code covered. That target should be adjusted based on observations. Make it too low, and more defects will get through undetected.

Technical debt is not necessarily bad or good. It is just the nature of the beast. The key to managing technical debt effectively is understanding its use and addressing the debt in a timely manner.  Acquiring technical debt may help to achieve a short-term goal, but one should have a plan in place to address it going forward. While it is unrealistic to think technical debt can be avoided, it can be minimized and managed.

Bringing in a professional testing team like Lighthouse Technologies early on in the project reduces the risk associated with technical debt. This is achieved by our expertise in identifying defects in early work products and throughout the development process so they may be addressed quickly before they become time consuming.

To learn more about how to minimize unplanned technical debt, and prioritize the impact of technical debt on your existing projects: Contact us now!