I came across an excellent satirical blog post about software development: How to develop unmaintainable software. The opening line resonated: “I get paid to take on technical debt.” We at +Confluent Forms LLC find ourselves increasingly in situations handling accrued “technical debt” on inherited client projects and find a lack in understanding of the term.

Technical debt is the deference of long term outlook for short term results. Because this is so often accrued on a developmental level, the full impacts are not usually realized until the deficit is already significant and ramifications sometimes dire.

The Origin of Technical Debt

Most often technical debt is a function of the Project Management Triangle, where there is a binding relationship between cost, time and scope. Quality is often put in between those as the overall factor being manipulated, also seen as the good/fast/cheap Project Triangle.

The Project Triangle

One of the marks of quality in a technical project is the ability to continue being refined in such a way that the overall lifetime of the project can be extended. This is considered good, and good follows from work, work that is neither fast or cheap.

Quality may result from interrelated factors like: environment selection, long term flexibility, maintainability, plentiful documentation, coherent structure, separation of concerns… Because so many of these are developmental considerations they, for the most part, are known only to the developers, and their value not conveyed to the project owner. Quality lives in a place few can view, less can understand and only with time may some appreciate.

Compounding Deficits

Therefore, often, quality is deemed the malleable consideration as budget (cheap) and timeline (fast) are easier to quantify and more pressing. Technical debt is sacrificing quality for immediate results. Worse, poor quality begets poor quality as debt becomes greater debt. As this compounds, and more work is done to keep the project going, the project becomes more unwieldy and the cycle continues. The costs of operation and modification multiply as quick and cheap yield to slow and expensive. As with any deficit the debt service (cost of maintenance) eventually becomes overwhelming to a point where even the minimum becomes maximum in cost and effort.

Even at this point, when the project is overwhelmed by it’s own technical debt, it continues. Stakeholders will cling and claw to the devil that is known. The debt never goes away, it is simply compounded until the system collapses. At which point, a new solution must be found, quickly and cheaply… it is a brave project owner that takes a stand, declaring “The first time around we sacrificed quality for fast and cheap, and now we’re paying for it. This time, we need to focus on Quality.”

Signs that you are incurring Technical Debt

How often have you heard phrases such as:

  • This will be a temporary solution until we have the budget to support doing it right
  • If we just customize this existing module (built for something unrelated  it will get us sort of close to our needs
  • It keeps crashing, but if we put more RAM in the server, add some buffering, and maybe some caching, it seems to get better

These are all signs that your solution is incurring debt, debt that will eventually sink your solution or cost you a lot more time, effort, and money to fix properly, similar to putting a bandaid on a cut and waiting until it has gangrene.

Need help addressing your technical solution, to escape your technical debt? That’s where we can help with our virtual CTO services or technology audit services.

Recent major examples of Technical Debt failure

On July 8th, 2015 the NYSE went down for a day, all mainland US flights on United Airlines were grounded, and the website of the Wall Street Journal went offline. This was one day after a huge drop in the Chinese stock market. It is likely that all of these events occurred due to incurred technical debt.