The topic of technical debt is, oddly enough, a somewhat heated debat amongst software engineers and architects. Like many traditional engineering projects, for example the construction of a building or the design of chemical plant, software engineering projects are built up over time. They’re modified, improved upon, and sometimes completely repurposed from their original design. There are two major differences that affect software engineer projects - first they are often developed and evolve at dramatically faster speeds. While it’s not surprising for a building to be in use fifty, one hundred, or even several hundred years after its construction, an old software system is a decade old, and only a very few systems are more than two or three decades old. Secondly, in most cases a single person or organization is in charge of a building or plant. Software, on the other hand, is typically a non-rival good, which means that multiple individuals and groups are using it at the same time and potentially influencing its evolution. This allows for a huge variety of stakeholders to have their say in a project.
In this research conducted at the IBM TJ Watson Research Center we interviewed various enterprise developers, architects, product managers, and other stakeholders to understand how they view technical debt on engineering projects. We discovered that many stakeholders view technical debt as a strategic decision that can be modeled in a manner similar to options theory. That is, they view technical debt as an expense that may be exercised in the future and their perception of the probability of this option being exercised influences their desire to take on this debt.