Hi, Tproger. We are a T1 Cloud cloud provider. In our blog we plan to talk about current topics from the IT world, including system administration, cloud technologies and development. Subscribe so as not to miss all the most interesting and useful.
Today we decided to talk about technical debt. Some consider it an integral part of the workflow, while others hold developers responsible for it. Let’s consider different points of view and approaches that simplify the work on the task stack.
On everyone ‘s ear
The concept of “technical debt” was introduced by the pioneer in the field of extreme programming and the inventor of wiki technology Ward Cunningham back in the early 90s. With this metaphor, he outlined the compromise that developers make when writing code in order to finish the product on time.
For more than thirty years, this term has been firmly entrenched in the IT community. It is often mentioned in the media and discussed on specialized sites. Corporate heads, analysts and independent developers all talk about the need to fight the coding debt.
It is clear that the overgrown technical debt slows down the development of new products and increases its cost, and also negatively affects the mood in the team. At the same time, excessive compromises make it difficult to write tests, and platforms for evaluating code quality cannot fix the situation. In most cases, they highlight only basic errors — for example, declared but unused libraries.
Companies around the world allocate about $85 billion annually for refactoring tasks. And there are still discussions about the reasons for the appearance of coding debt — for example, some experts are convinced that the developers themselves are to blame for this. Therefore, sometimes the metaphor of debt is used to justify the poor quality of the code, despite the fact that back in 2009 Ward Cunningham himself spoke out against such an interpretation of the definition.
Writing an optimal program requires a lot of time and effort, however, if the development team needs to prepare a release urgently, it’s easier to cut corners and clean the code another time. But as you know, there is nothing more permanent than temporary. Hastily assembled code gradually becomes legacy, and after a few years, services appear, the internal structure of which is known only to “the very retired engineer”. As a result, the old codebase slows down internal processes, and developers are increasingly pushing back releases.
However, there is an opposite point of view in the IT community – programmers cannot be blamed for the growth of technical debt, and in practice everything is much more complicated.
Technical debt is inevitable
Launching and maintaining a complex software product is an unpredictable process. We have to take into account financing, customer requests, unforeseen bugs and dozens of other factors affecting development. Back in 1992, Swedish scientist Ivar Jacobson introduced the concept of software entropy. Thus, with the expansion of the code base, the measure of disorder increases, and in conditions of chaos, the accumulation of technical debt is inevitable.
Potential sources of coding debt also include managerial miscalculations related to corporate methodologies and policies. Technical debt implies a compromise between speed and code quality, but the latter value is subjective. Even a good program written by one engineer may not be liked by another specialist (moreover, after a while it may cease to suit the author himself).
To unify the process and avoid endless refactoring cycles, it is customary to use the concept of Definition of Done (DoD). This is a set of criteria showing that the new functionality meets the internal requirements and is ready for use.
But according to a study by analysts from Stepsize, a company developing a bug tracker of the same name, most organizations lack standards for processing technical debt. At the same time, their implementation can accelerate the launch of products by 100%.
Another problem that leads to the proliferation of coding debt is errors in the implementation of flexible methodologies. For example, Martin Fowler, author of books on software architecture and refactoring, adheres to this point of view.
Companies neglect to create a software product roadmap and a basic set of practices, as a result, they implement not agile, but “false agile” (sometimes called “dark agile” or “dark scrum”). Managers build inefficient processes, as a result, developers suffer, who are also forced to make suboptimal decisions and accumulate technical debt.
By itself, technical debt is not something bad. In a sense, it is a tool for achieving goals. According to the author of The Cloud Pod podcast, Justin Broadley, it becomes a problem only if the development team ignores the subsequent refactoring.
However, there are also proactive techniques that are designed to prevent (or at least postpone for a long time) the appearance of legacy code. One of them is the concept of technical credit. In this case, the development team does not focus on the minimum set of features needed to launch the product, but seeks to anticipate the needs and simplify the introduction of new features in the future.
Another approach to combat the proliferation of technical debt is to reduce the influence of entropy. To do this, it is necessary to reduce the range of tools and frameworks used.
For example, the low-code approach is suitable for active prototyping and hypothesis testing in some situations. It involves launching and modifying services without writing code — instead of programming languages, such platforms use graphical interfaces with drag-and-drop functions. They standardize the stack and reduce the cost of support, and development cycles are accelerated.
By the way, Gartner predicts that by 2023 more than half of medium and large corporations will work with low-code platforms in one format or another.
In general, the issue of technical debt is a complex problem that is tied to management processes within the organization. In this context, it is wrong to hold programmers solely responsible for poor-quality code. But the revision of working approaches helps to prevent the growth of technical debt and accelerate the launch of new products.