This article gives an illustration of the emergency mode at a software publisher. One of its most striking consequences is the accelerated creation of technical debt.
Let's take a digital solutions provider: its existence depends entirely on the monetization of its software product. That's why it's likely that at some point it will slip down the slippery slope to hell.
All it takes is one triggering event to make this editor switch. For example, it will be the loss of a critical resource (departure of the developer who had everything in mind). It could be linked to a critical role (a failing CTO). Or it could be a sudden work overload (a big business opportunity quickly requires an additional module). In reality, the triggering event is a simple fuse that sets off the devastating potential of significant unaddressed dysfunction. For example, in the case of the departure of a critical resource, we will end up with insufficient documentation and a lack of management of the scarce resource.
Sometimes it is simply an accumulation of micro-dysfunctions over the years, without even needing a triggering event.
At some point, someone tells the development team: "We have to make sure it's out by such and such a date". And that's when the trouble starts.
Generally, when faced with strong deadline pressure, developers identify shortcuts and make temporary arrangements, more or less coordinating their choices.
When emergencies become a technical debt
Besides possible shortcuts to good software development practices, the quality of the design will also be degraded. Why? For the simple reason that good design requires time, collective intelligence, and maturation. And when this time is not available, the design is of lower quality. This will limit the scalability of the software, for example.
So these are purely mechanical effects. Developers don't want to "work badly", but they simply don't have the time to "work well". This includes producing code that is sufficiently modular, well documented, and follows good practices for configuration management, coding, etc.
And more often than not, liberties with good development practices have been taken. Even if the teams sincerely plan to clean up the code as soon as the emergency is over.
This rarely happens in reality.
Several phenomena will prevent this squaring off. For example, other emergencies will arrive. And the real capacity to produce will probably have become lower than its theoretical capacity (because diminished by the effects of untreated dysfunctions).
One of the unaddressed deficiencies is the technical debt. If it is not resolved, it will indeed start to "cost" in interest.
The legacy code
This process is indeed a descent into hell. Each additional step towards the depths enriches the vicious circle with new dysfunctions.
As soon as this technical debt exceeds a significant level, it will indeed influence the production capacity and the quality of the product. It is a factor of accelerated constitution of what is called "legacy" code.
In short, legacy code results from the "mess" inherent in coding new features (without specific deadline pressure) if nothing is done to check and clean up as you go. This is comparable to using a living space. We keep it clean and tidy by small gestures during different uses. It would obviously quickly become messy and dirty without this attention.
The transformation of the code base into legacy code will undergo an uncontrolled acceleration effect with a specific delay pressure, with the multiplication of small technical debts. This accumulation of degradations creates such a massive phenomenon that we speak of "technical debt". That is to say, it becomes a parameter in its own right that now impacts the life of the software product.
How to recognize legacy code?
This legacy code is easily recognized by the difficulty of using it and maintaining it in operational condition. The insufficient application of good development and maintenance practices have made it less and less understandable. Developers no longer have the means to relate the code to actual application behavior. Sometimes, this deep corruption goes beyond the development field. It affects the entire information system. For example, no one knows anymore what the expected application behavior was in certain situations. Or to what need such expected application behavior corresponded.
The major characteristic of legacy code is its unpredictability. Developers no longer have the means to estimate how long an intervention on the code will take. Generally, the strong coupling between internal components combined with the lack of clarity of the code makes any minor intervention a potential adventure of several days or weeks. A permissive language will for example allow the creation of aberrant or invisible objects. A Windev button may contain code, which is de facto hidden.
The consequence of the technical debt on the teams
Thus, there is no longer any link between functional complexity and code complexity (and associated work).
This development team is then unable to give reliable estimates. It can no longer respect its own planning, or even propose a plan.
The final picture is a demotivated, even exhausted development team. At best, they are dealing with legacy code that they are struggling to develop and maintain in operational condition. And for good reason: every time a software patch is released, "the walls shake". The result is surprising side effects, major or critical anomalies, and an explosion of customer calls.
The rest of the company generally considers the development team as incompetent. In particular, the customer instances (call center...), which suffer the effects of customer dissatisfaction. And the product (or business) management, which suffers from the difficulty of making the product evolve.
In short, the development team is held hostage by a technical debt that has gotten out of hand. It is accused by the rest of the company of gross incompetence or ill will.
However, the cause of the limitations suffered by the company is indeed technical. It is not the current responsibility of the development team. The latter does the best it can, most of the time, in a situation where it has no power to act as it is.
So what can be done to counteract the phenomenon of technical debt?
In addition to a specific strategy to deal with the technical debt (the symptom, which has become a cause of inefficiency) and to seek to regain a real production capacity, it will also be necessary to deal with the original cause at the origin of this slide into an emergency mode that has created technical debt.
Thus, there will be two types of approach (and two specialized expertises) to mobilize. A technical approach to resolving debt situations. And a broader organizational competence, which includes the process organization as well as the managerial one.
This organizational remediation is the subject of our article How agility can help free you from the tyranny of the emergency mode.
