The First Law of Technology Transfer: Long-range good tends to be sacrificed to short-range good.

The Second Law of Technology Transfer: Short-range feasibility tends to be sacrificed to long-range perfection.

Jerry Weinberg - Quality Software Management

In this discussion, the term: heuristic refers to a method used in a given context, with no guaranteed outcome, that possibly contradicts other heuristics, and which helps reduce the time required to find a solution. The acceptance of such heuristic depends on the context of use, and not on an absolute standard.

The term: state of the art (sota) refers to the set of heuristics that a person or a group uses at a given time in order to create the best possible solution to a problem only partially understood, in an uncertain situation, and using limited resources.

(For more information on these terms cf. Billy Koen, Discussion of the method or this presentation.)

Why I am done with "Technical Debt"

I would rather not use the expression "technical debt" in my work. I did so for a long time, but in the majority of cases where I currently use it or hear it used, this expression is inadequate, and even counterproductive.

For me, it has many flaws:

It is ambiguous: for some practitioners, it refers to a heuristic consisting in temporarily straying from a project’s sota in order to reach an intermediate goal. This is sometimes referred to as "tactical" technical debt. For many other practitioners, the expression refers to what constitutes a liability in a software artifact when it is deemed not conforming to the current minimal sota that is agreed on by our industry in general. This is sometimes referred to as "endemic" technical debt. It is this second meaning that seems to me an abuse of terms, and that I would rather not use in my work.

It is negative: it presents the solution building activity as a process that has destroyed as much or more value as it has created, and its agents as careless (or cornered) borrowers who didn't pay enough attention to the balance, that is to the consequences of their actions and decisions.

It is exclusively financial: it implies, tangentially, that "quality" (another term that I wish to stop using) has a cost that can be known, and that despite our inability to reduce that cost, we can still manipulate it, like a quantity that we put in front of the (also fictitious) value created by the software, in an equation that would determine "developers’ productivity".

A simple metaphor at the start, it has been promoted to an engineering metric, and marketed as such. The fact that solutions exist on the market that can evaluate (in dollars) technical debt shows the immature tendency of our industry to transform simple metaphors into pseudo-industrial instruments. "Technical debt", like "Test coverage" has to join in the waste basket of flawed concepts that, once instrumented, create at best an illusion of control.

It creates guilt by pointing fingers at the financial deficit caused by the poor quality of a solution, which brings to the fore Quality as a virtue (Prudence, Honesty, Health), and Poor Quality as a vice (Negligence, Dishonesty, Anemia). It is inviting moral clichés that define the "professional" developer as one to declare "I refuse to deliver sh.. whatever the pressure, or the rules I am surrounded with". It makes a hero of the software craftsman, while giving no perspective at all on the system that is creating the phenomenon being denounced.

It sustains the archaic, inadequate separation between "technology" and "business", functional and non-functional, by assigning to functional the invention of value, and to technical the responsibility for all the costs for the solution.

Lastly, it does not contribute to solving the problem that we are trying to put our finger on. "Technical Debt Management" has become one more activity in the set of roles and activities associated with software development. It mainly consists of measuring the phenomenon and its consequences while not addressing its causes.

Therefore, I wish to keep only this acceptation of the term "technical debt":

[Contracting Technical Debt] : heuristic by which one momentarily breaches the sota of a project in order to reach a high-priority, intermediate goal.

And I want to rid my vocabulary of the term "technical debt":

Technical Debt: general state of a solution deemed not conforming to the sota that is commonly agreed on in the software industry.

To assert that "this solution has technical debt", without considering the initial sota chosen by the group in the context of its project, is predominantly and mistakenly taking one's own sota for the initial sota of the given solution.

We have to put an end to "Technical Debt" (in general) as we have to put an end to "Quality" (in general). We can enumerate instead the qualities of any given solution in its context. These are the characteristics of the change that we seek to create when adopting a particular sota that is adapted to the context. But when I say "Quality", I'm implicitly referring to a minimal standard sota, that I suggest is valid in all contexts, i.e an absolute standard.

There is no absolute standard. There is no sota that we could denote by this word : Quality. At the Plaza Athénée restaurant in Paris, one can enjoy an excellent quality meal (for €380, beverage non included). And McDonalds, (where one can lunch for less than €8), has a quality management department.

Here's a quality software development project:

• the solution, created in only 200 days, has been tested and judged as sufficiently adapted to the problem at hand;
• the code and the documentation conform to the approved sota of the organization this software belongs to;
• defect prevention practices are at a level high enough to guarantee several releases per month without regression;
• the architecture is documented, and adapted to the ecosystem this software will be living in.

And here's another quality software development project:

• the solution, created in only 2 hours, is adapted to the problem at hand;
• the code is written in a scripting language that is easy to learn and documented;
• the script will be used only once;
• during the script execution, it will be possible to stop and resume operations in order to adjust some parameters;

What we have here is two quality projects, A and B. Adapt the quality criteria from project A to project B and vice versa, and you will get two absurd projects that no customer would agree to pay for.

An alternative

I can hear you challenging me, in a calm, collected tone: Perfect. No more "Technical Debt". What are you proposing?

I propose, in situations where one wants to talk about technical debt, to replace this expression with the expression : conflicting heuristics.

I propose to replace the phrase:

Our solution incurs technical debt.

With the phrase:

Our solution relies on conflicting heuristics.

This is for the short version. For a longer explanation:

Evidently, the heuristics we had tacitly or explicitly agreed on until now, which constituted the state of the art that was adapted to the solution we were envisionning, are not followed anymore, or have been modified, and are, in one form or another, in conflict.

The (temporary, incomplete, even fragile) agreement that was constituting the sota for our solution has thus to be reenacted, or the objectives of our solution have to be discussed anew.

Therefore, the very first thing to do in order to improve the situation, is not to "manage technical debt" or to "pay back the debt" in this solution, but to precisely identify the distinct heuristics that are conflicting in our sota and to solve this conflict.

Since it is aiming at a change in the way we consider a very common phenomenon, such an explanation will necessarily produce objections.

Objection #1: In our project, there never really was an "agreement on the sota". The heuristics that you say made up the sota never were explicitly stated, not to mention examined, and certainly not validated by the team. Exactly. This is exactly the reason why we found ourselves observing that "this solution has technical debt". Objection #2: Conflict or not, it is still technical debt, since it is the responsibility of the technical side (and not of the functional side, business, users, management, coaches, etc.). Without the functional side, the business, the users, the management, our solution would not  have "technical debt". It would just be an unusual, incidental, gratuitous object that some developers made because they could. There is "technical debt" because there is a conflict, and a conflict involves several parties. Objection #3: To get into the detail of all the heuristics that contributed to our solution as it is and in order to examine them, amend them, and put them back into a coherent set: all of this takes time. Could we not just simply fix the problems? In order to fix problems, one has to resolve the conflicts. If several heuristics that are used to  create our solution are contradicting each other, this contradiction will persist and the state of our solution will deteriorate. We must therefore reconcile these heuristics, or change the objectives of the project.

Objection #4: Do you have at least one (or ten) examples of situations where a solution is in "debt" due to a conflict of heuristics?

Yes (in my next article). Highlighting a conflict in heuristics in a project situation is easy, irrespective of this conflict being implicit or explicit. For instance, yesterday I tried until 8pm, to export data in order to create a "quick & dirty" diagram. I wanted to respond to the request of a customer who wants to get a clearer picture of its data with our software. I made the mistake of dealing with this request on my own instead of mentioning it during our standup meeting. I thought that coding this export in python and creating a graphviz diagram would take far less time than the time it would require for us to align on this task in an explicit manner, given the fact that I think I am the only one to master graphviz in the team.

At least four of our team heuristics were in a contradiction (explicitly or implicitly) in this affair:

[Extreme Customer Focus] : Propose to customers a unique experience in terms of responding to their needs while exceeding, if needed, the standard level of service.

[Quick & Dirty] : creation through a series of expedients with the dominant objective of delivering a solution within a remarkably short period of time.

[Consistent Code Review] : All the production code should be read by persons other than its authors.

[Consistent Unit Testing] : All the production code includes unit tests ensuring that the code conforms to its authors intention.

I made a trade off, thinking initially that a short script of twenty lines would suffice (the script is now 152 lines long), and that it was not production code, since this code was written outside the project's code base. As if the code that makes it possible to ship an artefact to the customer was not production code. In a nutshell, this little script constitutes the beginning of what we could call "technical debt", but that I would rather denote as : an artefact that was produced by means of conflicting heuristics.

Objection #5: the heuristics mentioned in your example don't represent an absolute standard. Other teams, or other organizations could very well admit totally different practices and heuristics.

There is no absolute standard. And if there was one, we would each make a relative interpretation of it. It doesn't matter much, since what is important above all, is that in our state of the art, heuristics should be in harmony, not contradictinig each other. Although knowing very common practices is obviously useful (why would we isolate ourselves from all the know-how that permanently accumulates everywhere on the internet or in bookshops and library shelves?), it is better to own one's state of the art, than to perfunctorily adopt some other place's "standards" that are not adapted to our context, and to which we conform because we "have to", and not because we have succesfully experimented with them.

Objection #6: It is hard to see how talking about conflicts can be a help in improving the situation. Communication within projects is already complex enough.

The same way that a resource conflict doesn't fatally end up in a battle, two conflicting ideas don't necessarily create a conflict between people. A project that would unfold without any conflict of ideas is probably not worth doing. But a project in which conflicts are neither approached nor solved is not a healthy project, but a project in agony.