Abstract
Social debt is analogous to technical debt in many ways: it represents the state of software development organisations as the result of “accumulated” decisions. In the case of social debt, decisions are about people and their interactions. Our objective was to study the causality around social debt in practice. In so doing, we conducted exploratory qualitative research in a large software company. We found many forces together causing social debt; we represented them in a framework, and captured anti-patterns that led to the debt in the first place. Finally, we elicited best practices that technicians adopted to pay back some of the accumulated debt. We learned that social debt is strongly correlated with technical debt and both forces should be reckoned with together during the software process.
Highlights
Software engineering success is increasingly dependent on the well-being of development communities [1]
In Layman’s terms, by social debt, we indicate the additional cost occurring when strained social and organisational interactions get in the way of smooth software development and operation
The case study was driven by the following research questions: “What are the factors at play around social debt during the software lifecycle? Are there patterns in said factors? Can they be mitigated?”
Summary
Software engineering success is increasingly dependent on the well-being of development communities [1]. In some of our previous work [2,3,4], we found many decisions influencing community well-being. Changing the organisational structure [5] of the development community (e.g., through outsourcing), changing the development process (e.g., by adopting agile methods), leveraging on global collaboration (e.g., by striking a balance between formal and informal communication across global sites) are all socio-technical decisions, i.e. social and technical at the same time, that influence the state and welfare of developing communities and their members [5]. The social connotation of these decisions, changes the way people work and interact with others - i.e., their organisational and social structure [4]. The technical connotation of these decisions, changes the way in which development tasks are worked out. For example using Kanban boards, a “pull” task-allocation is often used, as opposed to classic “push”
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
