Measuring and Managing Technical and Social Debt at once

Ipek is probably going to kill me 🙂 since she may still be skeptical for this social debt thingie, but, in my qualitative research experience in industry I have observed at least four times (i.e., in four different companies) an intense correlation (and, more often than not, causality) between social and technical debt. The force that Philippe, Hans and I called social debt a while ago is the result of accumulated sub-optimal socio-technical decisions (for example, choosing an interaction protocol based on wikis instead of emails) and is often resulting into circumstances that force technical debt onto would-be perfect code-bases. A trivial example I observed lately manifested with the addition of a new outsourced partner that forced architecture changes. In this sea of madness, a key research question I’m struggling to address now is:

What are the factors at play around the relation between social and technical debt? How can these be managed?

In my previous work, I stumbled more than once on this intense and often unpredictable relation resulted, for example in a series of organizational and socio-technical patterns. For example, the social debt conceptual model we developed as a result of an industrial case-study:


Also, there were several patterns we observed focusing on software architecture… These seemed to suggest ways in which architectures are themselves a pivot for driving the discovery and often the management of both social and technical debt… most notably, the “Architecture by Osmosis” social debt pattern from [2]:


We witnessed this very pattern iterated several times in a large industrial player extremely active in the aerospace software market… Essentially, disgruntled clients would call up operators, who would accommodate part of the required changes and alert developers, who would accommodate another part of the changes and alert architects who would change the architecture and connected decisions with little or none of the information that goes inevitably lost in the communication chain, i.e., the


chain. In the same paper, we tried to offer a tentative metrics framework that takes several organisational and social measurements to understand what could be the impact of social debt connected to miscommunication… this leads to a key challenge, I’ll be trying to address in the near and not-so-near future, that is:

A selected subset of different metrics and patterns for technical debt should be used or correlated to address and further investigate the interactions between technical debt and its social / organizational counterparts.

[1] Damian A Tamburri, Philippe Kruchten, Patricia Lago and Hans van Vliet “Social debt in software engineering: insights from industry” Journal of Internet Services and Applications – (2015) 6:10 DOI 10.1186/s13174-015-0024-6

[2] D.A. Tamburri, E. Di Nitto, “When Software Architecture Leads to Social Debt” WICSA 2015 Montreal, QC, Canada – May 4, 2015 to May 8, 2015 ISBN: 978-1-4799-1922-2