{"id":1281,"date":"2021-07-05T14:43:05","date_gmt":"2021-07-05T14:43:05","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1281"},"modified":"2021-07-05T14:43:06","modified_gmt":"2021-07-05T14:43:06","slug":"outdated-belief-4-technical-debt-results-from-poor-architecture-design","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2021\/07\/05\/outdated-belief-4-technical-debt-results-from-poor-architecture-design\/","title":{"rendered":"Outdated belief #4: Technical debt results from poor architecture design"},"content":{"rendered":"\n
\"\"
Photo by Alex Wong on Unsplash<\/figcaption><\/figure>\n\n\n\n

In the software community, there\u2019s a general belief that software ages, just like humans \u2013 David Parnas is famous for this quote (among many other things). Our findings don\u2019t confirm this. We\u2019ve studied architecture technical debt as well as other types of technical debt for a decade and we\u2019ve 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.<\/p>\n\n\n\n

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\u2019re 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Especially those that originate from mechanical and electronics disciplines, where the cost of changes after the start of production often is prohibitively high, tend to consider technical debt, especially for young systems, to be an indication that the architects did a poor job designing the architecture. As the saying goes, hindsight is 20-20, and it\u2019s easy, even for those with limited software expertise, to claim that it should have been obvious that certain decisions were the wrong ones.\u00a0 <\/p>\n\n\n\n

This claim is of course incorrect for at least two reasons. First, at the time the decision was made, there typically was much less information available than there is now. Second, what\u2019s important today from a business perspective is typically different from what was considered important when the decision was made. Many tend to forget that the business evolves continuously as well.<\/p>\n\n\n\n

In this context, I frequently use the BAPO model<\/a> to show the close connection between business and business strategy and the architecture and technology choices. The primary dependency should be that business drives architecture, architecture drives the process, ways of working and tools, and that these drive the organizational setup.<\/p>\n\n\n\n

In practice, however, it\u2019s the architects who are predicting where the business is going and proactively adjusting the architecture to optimally support the future business. As such, they set the real business strategy for the company, which is why close interaction between business strategists and system and software architects is so important. Preferably, the constant evolution of architecture occurs proactively, rather than reactively, so that the architecture is always optimal for what the company needs at any point in time.<\/p>\n\n\n\n

This also means that I\u2019m highly skeptical of new platform and architecture initiatives. Rather than letting the existing architecture \u2018rot\u2019 until it\u2019s no longer usable and then kicking off the development of a new architecture, it\u2019s much better to continuously invest some percentage of your R&D resources towards architecture refactoring. This has two main advantages. First, you never suffer through a period where the architecture is poorly supporting the business because it\u2019s outdated. Second, it avoids the high risks associated with new platforms \u2013 the investment is often quite high and reaching feature parity with the existing platform is time consuming and expensive.<\/p>\n\n\n\n

Identified technical debt in your architecture is a positive, rather than a negative, aspect of your software R&D. If you wouldn\u2019t continuously invest in addressing technical debt, your architecture would rapidly start to age and become outdated. That aging isn\u2019t the consequence of bad decisions but rather an inherent property of a continuously evolving business. Different from humans, software doesn\u2019t have to age but can be perpetually young and optimal, as long as you prioritize technical debt management sufficiently. Imagine never having to build a new platform, with all the associated risks and costs, because your current one is fit for purpose at all times.<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at\u00a0<\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

In the software community, there\u2019s a general belief that software ages, just like humans \u2013 David Parnas is famous for this quote (among many other things). Our findings don\u2019t confirm this. We\u2019ve studied architecture technical debt as well as other types of technical debt for a decade and we\u2019ve generated all kinds of results. One … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[9,8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1281"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1281"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1281\/revisions"}],"predecessor-version":[{"id":1283,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1281\/revisions\/1283"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}