Technical Debt Through Analogy: Call…

Technical Debt Through Analogy: Call for “Twin Assets”, Benchmarks, Artifacts and Repositories

Research Questions:

How can we predict the likely technical debt before we build the software? Can estimation through analogy, which is respectable in science, help here? How can the concept of “twin assets” in finance serve the above objectives? How can we identify these twins? The twins can relate to various concerns – how can we decide on these concerns, manage and reconcile the relative debts?

Need:
As a community, we may need to define benchmarks, call for artifacts and repositories which can assist the estimation of debts through analogies. The infrastructure can be specifically useful in estimating debts that can relate to non-functionalities – which are difficult to predict and visualize even in existing software.

An Example – Closely related work:

Though the work does not mention “technical debt” in its exposition, the treatment of debt is implicit. We had used spec.org (Performance benchmark repository). We had estimated the value of architecture decisions under uncertainty – relative to scalability scenarios of interest:

R. Bahsoon and W. Emmerich: An Economics-Driven Approach for Valuing Scalability in Distributed Architectures, WICSA 2008

Drawing on a case study that adequately represents a medium-size component-based distributed architecture, we show how existing performance repositories could be mined to value the ranges in which a given software architecture can scale to support likely changes in load. The mining is based on a financial analogy, where we utilize the concept of twin asset in financial engineering to justify mining relevant repositories. The mining process in then complemented with real options analysis for predicting the values resulted from the ranges in which an architecture can scale under uncertainty, where uncertainty is attributed to the unpredicted change in load. As the exact method for analyzing scalability is subject to debate, we focus the analysis on throughput as a way for measuring scalability. Using options analysis, we report on how ranges in which an architecture can scale, can inform the selection of distributed components technology and subsequently the selection of application server products.

I have recently tailored the above analysis to the benefit of cloud service selection. Work published in MTD 2013, UCC 2013 and Australian Software Engineering 2014.