Technical debt results from poor architecture design – Bits & Chips
In the software community, there is a general belief that software ages, just like humans – David Parnas is famous for this quote (among many other things). Our findings do not confirm this. We have studied architectural technical debt and other types of technical debt for a decade and have generated all kinds of results. One of our most surprising findings, resulting from a survey of hundreds of respondents, was that there does not appear to be a correlation between the age of the system and technical debt.
Our hypothesis to explain this is that there is always technical debt but that the type of debt changes over time. Young systems often have a technical debt because architects operate with great uncertainty as to the optimal way to achieve the desired functionality and therefore make decisions which, in hindsight, prove to be suboptimal. For established systems, there is often a debt due to the required system scaling. This renders functionally correct design decisions incapable of meeting non-functional requirements. Finally, for older systems, we are more frequently faced with technological obsolescence where components have to be replaced by newer alternatives and where, for example, the architectural style has to be replaced to meet new knowledge.
As an example of the latter, many embedded systems used a monolithic software architecture where components can directly call and sometimes even access a global variable space. This allows high computational efficiency, but results in low development efficiency. Many organizations that build embedded systems are now exploring a transition to containerized components or subsystems and message bus-based communication. The latter sacrifices some computational efficiency, but less than one might expect, and allows for much higher development efficiency as well as updating individual components rather than the entire image.
Especially those coming from mechanical and electronic disciplines, where the cost of modifications after the start of production is often prohibitive, tend to view technical debt, especially for young systems, as an indication that architects have done a bad job. architecture design work. As the saying goes, the hindsight is 20-20, and it’s easy, even for those with limited software expertise, to argue that it should have been obvious that some decisions were the wrong ones.
This assertion is of course wrong for at least two reasons. First, at the time the decision was made, there was generally much less information available than today. Second, what is important today from a business perspective is usually different from what was considered important when the decision was made. Many tend to forget that the business is also constantly changing.
In this context, I frequently use the BAPO model to show the close connection between the company and the business strategy and the choices of architecture and technology. The main dependency should be that the company drives the architecture, that the architecture drives the process, work methods and tools, and that these drive the organizational configuration.
In practice, however, it is the architects who predict where the business is going and proactively adjust the architecture to optimally support the future business. As such, they define the true business strategy of the company, which is why close interaction between business strategists and system and software architects is so important. Preferably, the constant evolution of the architecture occurs proactively rather than reactively, so that the architecture is always optimal for the needs of the business at all times.
It also means that I am very skeptical of new platform and architecture initiatives. Rather than letting the existing architecture “rot” until it is no longer usable, and then launching the development of a new architecture, it is better to permanently invest a certain percentage of your R&D resources. in the refactoring of the architecture. This has two main advantages. First, you never suffer from a period when the architecture does not support the business because it is obsolete. Second, it avoids the high risks associated with new platforms – the investment is often quite high and achieving feature parity with the existing platform is time consuming and expensive.
The technical debt identified in your architecture is a positive, rather than negative, aspect of your software R&D. If you weren’t continually investing in dealing with technical debt, your architecture would quickly start to age and become obsolete. This aging is not the consequence of bad decisions but rather an inherent property of a constantly evolving company. Different from humans, software does not have to age but can be perpetually young and optimal, provided that technical debt management is sufficiently prioritized. Imagine never having to build a new platform, with all the risks and costs associated with it, because your current platform is fit all the time.