Outdated belief #4: Technical debt results from poor architecture design

In the software community, there’s a general belief that software ages, just like humans – David Parnas is famous for this quote (among many other things). Our findings don’t confirm this. We’ve studied architecture technical debt as well as other types of technical debt for a decade and we’ve generated all kinds of results. One of our most surprising findings, resulting from a survey with hundreds of respondents, was that there seems to be no correlation between system age and technical debt.

Our hypothesis to explain this is that there always is technical debt but that the type of debt changes over time. Young systems often have technical debt as the architects operate under a lot of uncertainty about the optimal way of achieving the desired functionality and consequently make decisions that in hindsight turn out to be suboptimal. For established systems, there often is debt due to the scaling required from the system. This causes functionally correct design decisions to be unable to satisfy non-functional requirements. Finally, for older systems, we’re more frequently dealing with technology obsolescence where components need to be replaced with newer alternatives and where, for instance, the architectural style needs to be replaced to meet newer insights.

As an example of the latter, many embedded systems used a monolithic software architecture where components can directly call each other and sometimes even access a global variable space. This allows for high computational efficiency but results in low development efficiency. Many organizations building 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 would expect, and allows for much higher development efficiency as well as updating of individual components rather than the entire image.