Habya ' A (improvised components) with technical debt

We have had the deadline coming and the time is very tight. At that time, we must fix the bug as soon as possible, but one of the bug is particularly tough, let us make every effort also helpless! Then, one of my colleagues took over the debugging work. He was forced to write values that should be retrieved from the database-they would not change during the first few months of the system's operation-and then ... The system magically works!

For this kind of "inexplicable code", my colleague called it "Habya ' a" in the most interesting Egyptian slang, meaning a makeshift piece of kit.

My colleague is similar to his creative slang, and Ward Cunningham called this bad code "technical Debt" in 1992--the Wikipedia definition of technical debt is "1 of the work that needs to be done before a task is judged to be done", and Steve McConnell defines technical debt as "a design or construction approach that is a short-term expedient-because it creates a technological environment in which the same work is required to be done later than it is done now." "2

If we look at technical debt from a pragmatic perspective, we will find that it is not always a bad thing. When the deadline has expired, the technical debt is equivalent to pay for the delivery of "highway tolls." Another friend of mine once said to me, "technical debt is like parking where there is no parking area: parking is wrong, and it can lead us to a ticket, but sometimes we have to take the risk to catch up on an important date in the next building." ”

So, sometimes the cost of efficiency is more than everything! But technical debt must be settled early, and it is another place similar to financial debt in that it generates interest.

The interest here refers to the effort we have to make to maintain code and/or design in the process of maintaining the system with tight coupling, too large classes, untested code, or any other form of technical debt.

From my perspective, the total interest on technical debt is not fixed, but will grow over time. I mean, in the face of a system with a technical debt, we need to spend more on system maintenance in every sprint. This phenomenon stems from the following two factors:

Maintenance is likely to introduce additional debt, because any maintenance will follow the same code and/or design methods when there are some confusing code in our system. These new debts will consume more energy in the next maintenance, and this will be repeated.

Over time, with no adherence to design patterns and lack of documentation, more developers will be able to patch the system differently, starting with their own assumptions about how the code or design fragment works. There is no doubt that this will introduce new bugs into the system. And revising these new bugs will introduce more bugs ...

For the above reasons, each interest rate will "contribute" to the growth of the technical debt, so the interest here is actually a form of compounding. Compounding is calculated using the following exponential formula:

Yt = Y0 (1+r) t

Here, YT is the debt value at the T Sprint, Y0 is the debt initial value, R represents the growth rate, and T represents the sprint ordinal number. In the Agile Project Environment, the T "is an integer, so here we can say that the technical debt will grow geometrically over time (because the geometric function is a particular case of the exponential function-3 when the" T "in the exponential function always takes the integer value).

As a result, the system will become more vulnerable and difficult to maintain as the cluttered code base accumulates. Another side effect of the increase in interest on technology debt is that the productivity of the team has been suppressed by the increasing amount of time spent on maintenance.

In a project, we have been enduring such a bad code practice for a long time, when we finally entered the stage before the formal engagement, the system suddenly collapsed! It is impossible to refactor while avoiding significant impact in many parts of the system, so we decide to do it all over again!

Fig. 1 The cumulative histogram shows the tendency of the interest of technical debt to grow geometrically over time. The figure uses a hypothetical value, not a real project data.