Sustainability Debts The recent manifesto…

Sustainability Debts

The recent manifesto for sustainable design has identified a number of dimensions that can directly or indirectly influence the sustainability and longevity of a software. Roughly speaking, these dimensions can relate to the individual, society, economics, environment and technical.

It can be argued that a sustainable software shall deliver and sustain its value across these dimensions – while the system is in operation and as it evolves. The presence of debt on any of these dimensions is a threat on sustainability and may call for phasing out the software.

Research Questions:
How does the concept of debt and interest on the debt relate to the sustainability dimensions?
How can we predict, quantify and visualize the debt across these dimensions?
How can we manage the debt across these dimensions: negotiate and reconcile the conflicting objectives?

Closely Related Effort:
B. Ojameruaye and R. Bahsoon(2015). Sustainability Debt: An Economics driven approach for Using Technical Debt Analysis in Decision Making for Sustainable Requirements. CSR-15-03 Technical Report. School of Computer Science, University of Birmingham, UK (under submission – ICSE Software Engineering for Society).

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?

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 (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.