BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Managing Technical Debt Using Total Cost of Ownership

Managing Technical Debt Using Total Cost of Ownership

This item in japanese

Bookmarks

Total Cost of Ownership (TCO) can be used for investment decisions and financial benefit analysis. When applied to software it covers the initial development costs and subsequent maintenance costs until phase out of a product. TCO can support architectural decisions and management of technical debt.

Hans Sassenburg talked about total cost of ownership analysis at the Bits&Chips Software Engineering conference. In his talk Sassenburg showed several metaphors that can be used to "sell" the concept of TCO. The metaphor of technical dept is easy to understand, but people often find it difficult to see technical debt increasing during the product lifecycle and take action said Sassenburg.

InfoQ did an interview with Sassenburg about using the total cost of ownership concept for managing software development, the main causes of technical debt and how to reduce technical debt or prevent accumulation of debt, managing R&D investments and costs and improving the quality of software products.

InfoQ: Can you briefly explain the Total Cost of Ownership concept?

Sassenburg: The concept of TCO has existed for over a hundred years, its roots date back to the first quarter of the twentieth century. The Gartner Group popularized it in the eighties of the last century. TCO, when incorporated in any financial benefit analysis, provides a cost basis for determining the total economic value of an investment. Practical example is the purchase of a car. For example, the TCO defines the cost of owning an automobile from the time of purchase by the owner, through its operation and maintenance to the time it leaves the possession of the owner. Comparative TCO studies between various models help consumers choose a car to fit their needs and budget. TCO also has its application in the software industry, albeit with a somewhat different interpretation. We now consider the total cost of a software product (standalone or part of an embedded system), making distinction between its initial development and the subsequent maintenance phase. The concept of "maintenance phase" is misleading here however, because we do not only fix bugs during this phase (corrective and preventative maintenance), but are also adding new functionality (perfective maintenance). In summary, TCO for software is no rocket science, its application considers the estimated total cost divided across the whole lifecycle.

InfoQ: Please elaborate how decisions that are taken during the initial product development will have impact on the total life cycle costs of a product?

Sassenburg: During the initial development, a common pitfall is that insufficient effort is reserved for evaluating the proposed architecture. In addition, compromises are made. This is due to time constraints on the one hand, but it may also be that the proposed architecture is too complex to be evaluated with non-mathematical methods. Last but not least, it is a challenge to take the unknown future extensions into account in an initial architecture.

After the architectural design, the implementation phase starts. Software engineers have the choice to implement new features in two different ways: one is to do it quickly and dirtily, which will make future changes very hard. The other is a smart and clean solution, which takes longer to implement, but makes changes easier in the future. Although dirty code or code with limited test coverage may work perfectly for customers if it delivers the desired business value, it will lead to an inflexible software product. Dirty code heavily undermines the reliability, testability and maintainability of the product, with adverse consequences for productivity and quality.

InfoQ: What in your opinion are the main causes of technical debt?

Sassenburg: There are two main causes of technical debt, as can be concluded from the answer to the previous question. The first cause is wrong decisions and compromises made during the architectural or design phase (design debt). The level of technical debt goes further up in the case of low-quality code implementation (code debt), being the second main cause.

InfoQ: Can you give some examples of things that can be done to reduce technical debt or prevent accumulation of debt?

Sassenburg: Let us start with the question how existing technical debt can be reduced. Typically, code debt can be reduced through refactoring, i.e. restructuring existing messy code. A successful approach here can be to explicitly reserve effort in each subsequent release to improve the code quality. In addition, companies can introduce stricter coding standards and enforce the rules that changed code may never have lower quality and that new code must comply with coding standards. The situation normally becomes more difficult in the case of design debt, which cannot be solved within small refactorings. Instead, there is now normally a need for redesigning smaller or larger parts of the product, that affect interfaces between components or modules. Preferably, one or more cleanup-releases are scheduled to reduce or eliminate the existing design debt. The management/business side must support this approach because it might delay new features.

InfoQ: Which advice do you want to give to R&D managers if they are looking for better ways to manage investments and their development and maintenance costs?

Sassenburg: A relevant question here is whether technical debt can be avoided at all. If so, the total cost of ownership costs will be lowest across the whole lifecycle, covering both development and maintenance. From an investment point of view, this would be the desirable situation. In the case of architectural decisions, the adoption of formal methods to verify designs is highly recommended. Moreover, if we can automatically generate source code from verified models, we can eliminate the contribution to technical debt by low-quality source code. Although we see a positive trend in using formal methods (e.g., Dezyne from the company Verum Software Tools), wide adoption is still waiting.

If the adoption of formal methods is too premature for an organization, two recommendations can be made, to be followed even in the case of extreme time pressure. The first is to reserve sufficient time for exploring and evaluating multiple design alternatives. The Software Engineering Institute has developed and published several techniques in this area to structure this process (e.g., ATAM). The second recommendation is to enforce strict programming standards as well as high test-coverage (especially during unit testing). The TIOBE Quality Indicator (TQI) is a very good example how code quality targets can be defined and monitored from a management perspective.

InfoQ: What can you do to enable better communication when it comes to managing the quality of products?

Sassenburg: You can question here whether the communication between engineers and managers needs to be improved. In many organizations, it is not that managers within R&D need convincing. The better ones already understand that technical debt can cause serious problems in the future if it is not managed.

The problem may be more on the side of business managers outside R&D. Business management often has little understanding of the importance of software engineering within R&D and tends towards underestimating its contribution towards a successful R&D outcome. R&D managers are confronted with the reverse problem. They have a deep understanding of the importance of software engineering but find it close to impossible to communicate this to business management. Common issue is that they all face the pressure to deliver, and that delivery is often judged by their managers outside R&D against a date and not against a quality target. Put differently, there is probably more a need to improve the communication between R&D managers and non-R&D managers.

An approach to overcome this barrier is using a metaphor to build a house with Lego bricks. Using a cleverly designed exercise, it can be made clear how choosing a wrong foundation (= bad architecture) and choosing the wrong colour of stones (= programming errors) leads to major problems in the future not only for R&D but also for the business. New product enhancements become increasingly expensive and time-consuming to achieve and customers start more and more complaining about errors that keep surfacing. It’s an investment of half a day only.

The Bits&Chips Software Engineering conference. is held at the High Tech Campus in Eindhoven, the Netherlands on June 3:

Engineering robust, reliable software for today’s industrial systems is a major challenge. Software increasingly embodies the intellectual property that enables businesses to compete and as such is one of the major pillars upon which the success of a growing number of companies depends. And yet software engineering as a discipline often fails to meet the needs of organisations that are more and more dependent on it.

The Bits&Chips Software Engineering conference brings together leading figures from industry and academia to exchange knowledge, ideas and experiences about the challenges of engineering current and future generations software systems.

InfoQ is covering this conference with (live) news and articles. The following Q&As have been published last week:

Rate this Article

Adoption
Style

BT