Marsel Gray
Category: Development
11.25.2020
Technical debt is a concept in software development that attributes future problems to the implied cost of an easy, quick solution now instead of using a better approach that would take longer. Technical debt like all debt can and will accrue interest and on the day it comes to pay that, you’ll be glad NJI’s Development Team not only has a thorough understanding of technical debt but actively works against adding it to the codebase.
The origins of technical debt are many. They range from poor testing, lack of developer knowledge, nonexistent documentation, tightly-coupled components, to insufficient up-front definition. There are more but one I see often is insufficient up-front definitions. This is where technical debt begins to accrue even before the first line of code is written. It mainly occurs where requirements are still being defined during development and/or development starts before design. While this is done to save time, it rarely is the case. There is a tendency to view web pages as independent concepts from one another with each page being individuals. This is far from the case and in violation of one of the main concepts with coding: DRY (don’t repeat yourself). It helps to think of a website or application as a machine with different and also similar working parts. Code is highly interdependent and layered.
Another common source of technical debt comes from a poor Define Stage. This is where lack of alignment to industry standards, frameworks, or technologies leads to future problems. When we see requests or designs with little thought to the user or client, the Development Team aggressively question what is the user story and experience here. This gives us better insight into how to build upfront before code is even written. There is a tendency for people to view bugs as mistakes rather than a conditional not accounted for in the original build. Code often does exactly what it’s programmed to do and if a certain feature or component was not designed or its intent not communicated properly to the development team then it may work as intended, just not the way organizations. If developers do not ask the right questions about proposals, then technical debt is building up.
“There is a tendency for people to view bugs as mistakes rather than a conditional not accounted for in the original build.”
The last and most commonly seen technical debt we come across are requested “hotfixes.” This might be a new bug that has just only presented itself as the last moment and the fix is needed in a hurry. A developer may patch it quickly to save time but without the proper code or devotion needed. Going back to the machine metaphor, while they may have tightened a screw here, pressure on a pipe is building elsewhere. This is where interest on technical debt begins to build up and overtime makes changing legacy code a taxing and time consuming task.
The real truth is that technical debt is unsexy and few want to talk about it. Every project has it, it’s the elephant in the room, the unspoken truth. So what can be done to prevent it? How does NJI’s Development Team work against something universal to every project?
Let’s trace our story back to the origin of a project. Preventing technical debt begins with giving reasonable estimates. Ideally all projects would go quickly and some go faster than others given technical feasibility and bandwidth. The first step to preventing technical debt is planning and estimating time reasonably. Taking the project management “triangle” of quality, time, and cost. Only two can exist while the third must be sacrificed. A project can be of superior quality and completed quickly but it’ll cost money. Or a project can be of superior quality and completed a reasonable price but it’ll take time. And that’s usually the case. Good code takes time.
Another method to preventing technical debt is what I refer to as compound knowledge. Each project gets better and better as we learn from the previous ones. In a business world, time is money but prevention is also worth a pound of cure. Take this example, one of the many requests we would get often were spam emails to contact forms on websites. A recaptcha or honeypot would be added. Nowadays, we take the time at the beginning of the build to add this to any contact form we code. While it takes a few extra steps at the beginning, it saves future time and client dissatisfaction.
Much of what developers do is about managing risk. Nothing when it comes to technology is 100%. Development concepts like security, performance, accessibility standards, and technical debt are practical realities of the industry. Achieving these in websites is vital and not often discussed. But they are real, unsexy truths that need to be considered in every build, update, and new feature. Every team has to make decisions about where to start addressing technical debt. No two projects are the same so we exercise discretion about what is more prudent and pragmatic. Ultimately, creating a working agreement within the team covers how we assess and resolve technical debt
