Debt seems to be a hard concept to truly understand. I think everybody gets it, but then sink themselves in debt. As Brother Ali puts it, everybody wants to look good while they’re drowning.

Understanging debt in practice is hard. I think it’s because debt has many perceptions. Debt on its own is not really harmful. Sometimes it’s a good thing. Too much debt certainly is. Everything in moderation, right? Interest rates really makes the difference between good and bad debt. On the surface.

Nobody would really argue that 0% interest on debt is bad. But what if you don’t pay the principal in time? Or you’re late on a payment? There are a lot of variables. Those variables can have an impact that is hard to forecast.

Ward Cunningham originally developed the term and idea of Technical Debt. It has since been written about by people far more well-written than myself. It’s still apparently not widely understood or propagated. I see companies unwittingly incurring high levels of technical debt. Without batting an eye, even.

This amazes me. It seems that the people who should most understand these concepts simply do not. This is what technical executives are supposed to know, and they don’t. Technical executives who fail to understand this are doomed to an abysmal career. An abysmal career getting paid a lot of money, being duped by consultants and likely never having any accomplishments. To me that’s failing, others not so much. That’s why they ignore it.

I still find it hard to explain the concept to people who should understand it but don’t. It seems business owners have a different perception of technology. I don’t really know what that perception is. It’s no black and white, as in it works or doesn’t. They don’t even value quality in the same way.

When I explain it, I struggle. Especially when asked to cite sources (which any good executive will ask for.) I find it very challenging because it is a metaphor and then they try to extend that metaphor to things they more closely understand.

Here is a summary of how I view it and the impact it has on business. This is from my own attempts to explain the concept.

When any project is undertaken estimates are given for each component. (Well, hopefully. If they’re not they should be.) Estimates are important. Without a good plan a lot of hours will be wasted. Developers love to say a good plan isn’t necessary. Developers are often very, very wrong. Nearly any software product proves this.

The reason for this attention to detail is simple. Every component either increases or reduces technical debt. To be more specific, every decision increases or reduces technical debt. As mentioned above, some debt is fine. It can be lived with forever and never cause any issues. Some is disastrous. Some can go from harmless to harmful. Sometimes with little warning. It is very hard to determine what is harmful debt.

A common theme in the Mythical Man Month essays is the importance of a very solid architect. A lead that is responsible for all decisions of a system. I don’t mean they make every decision, merely that they are responsible. They sanity check everything. This person is the only source to be trusted on whether something incurs or pays off debt. This give a face to the debt of any product.

This is where I diverge from the explanation of technical debt and instead focus on solving the problem. Just like executives don’t need to know how to write software, they don’t need to know the details of technical debt. They instead need a policy and trust people to guide them. For this, I’ll talk about the role of the architect.

Architects Decide Success

Every organization should have architects leading products. Someone who is in charge of all technical matters. Every decision. A single source for all information. They should also have a backup (which can be a lead developer.)

Each decision contributes to debt. Sometimes debt is incurred deliberately. Debt knowingly accrued often is not negative. This idea can be harmful in practice, but is always good in theory. The negative outcome is because certain conditions can change and bring harmful debt where it was once benign. This is difficult to forecast.

A project must be delivered and must always have attributes that give a rough idea of the debt incurred. I have never seen a project that was shipped and forever neglected. There is always maintenance. Maintenance is where technical debt is paid.

The architects decisions directly relate to the bottom line for maintenance costs.

After maintenance is entered, a good opportunity is presented to put people being groomed for architect roles in place. They are now responsible for every technical decision regarding maintenance and growth. Mythical Man Month says this person should have served as a backup several times before taking the helm. Probably a good idea. However, it’s maintenance. The biggest decisions have been made and the debt is being paid off (hopefully). I believe that the best way to learn is to witness the mistakes made previously. This is ideal.

Good Code is Faster. Bad Code is Slower.

There is a trade-off with debt. That is time. To incur no debt (such a thing is not possible) is to write excellent code. Everything is well architected and designed to be future-proof (to me, future-proof means able to be replaced without harm in the future.). This takes slightly more time. Covering every edge case is a lot of decisions. It’s hard. It incurs an up front cost.

It’s up to the architect to determine what is worth the cost paid now, versus the cost paid in the future. Additionally, whether that decision have an impact before the project is complete. Sometimes debt is painful far too quickly in the life cycle of a project. Martin Fowler has an excellent point about this, all in one sentence.

The whole point of good design and clean code is to make you go faster.

Read that again, please. When a developer speaks about clean code or a good design they often times fail to articulate the reason for this passion. It’s very hard to explain this reasoning to non-technical people.

To continue this parade of analogies, it’s like wine tasting. Someone who rarely drinks wine (if ever) is unable to taste the details that are the most important. They simply are not present. However, in the case of quality developers they are being asked to pair the wine (the product) with dinner (the business).

There is much at stake, the customers coming in may not appreciate the technical merits of the wine but they will feel the quality of the pairing. Understanding this and the limitations

Forecasting Debt

There are different types of technical debt. Most must be incurred just as a matter of course. There is nothing more dangerous than a technical lead who is not learning new technology. Many thousands of people spend countless hours finding ways to do things better.

This almost seems counter-intuitive. If a technical expert uses the tools they know well, they should be guaranteed to succeed. Except they aren’t. Instead, they also duplicate the same mistakes through each project. Usually reserved for whoever is lined up for maintenance. If a technical lead chooses technology only which has proved successful in the past, the solution will be inefficient.

A race car using 5 or 10 year old technology would not be competitive. Software and tools are even more dramatically different. A solution 5 years old is likely to be riddled with high interest technical debt. The silver lining is there are usually many people well-versed in older tools. Most companies do not allow their technical people sufficient time to advance their own knowledge.

Often times if technical people are stifled, so are other parts. There is inadequate preparation for research and design. This lack of planning combined with an aversion of new techniques (or even as basic as allowing for mistakes to be made intentionally) yields painful debt. I believe this is the most common source for debt.

Leaders expect perfect solutions with poor planning from inadequately trained sources. They then fail to account for the inevitable mistakes. At that point, they wonder what went wrong. Basically, insolvency.