What is social debt in software engineering?

Accounting, Management and Information Technologies, 2000

A variety of experiences in software development processes between a public sector organisation and several software vendors over a decade-long period are described and interpreted. Three information systems histories are presented as case examples and their analysis is based on detailed insider observations. A social process model is used to describe the relationships between key actors within the client organisation while a transaction cost framework is used to explain the joint forms of the relationships between the client and the vendors. The resulting model depicts in a concise way how the relationships have evolved and stabilised over time. In this model, major encounters between the actors are those which have at least the potential to change the relationship state between the parties. The relatively stable passages between consecutive encounters are labelled episodes. By perceiving systems development as a series of encounters and episodes, it is possible to identify the critical turning points of development work and to display the dynamics of a software development trajectory. While our findings support the well-known basic software procurement principle, this is only after the trajectories have stabilised. Two of the three trajectories exhibit major changes in software procurement strategies before reaching a steady state. The paper ends with a discussion of the findings and some implications for researchers and practitioners.

International Journal of Systems and Service-Oriented Engineering, 2016

This paper discusses the possible changes that software engineering will have to go through in response to the challenges and issues associated with social media. Indeed, people have never been so connected like nowadays by forming spontaneous relations with others (even strangers) and engaging in ad-hoc interactions. The Web is the backbone of this new social era – an open, global, ubiquitous, and pervasive platform for today's society and world - suggesting that “everything” can socialize or be socialized. This paper also analyzes the evolution of software engineering as a discipline, points out the characteristics of social systems, and finally presents how these characteristics could affect software engineering's models and practices. It is expected that social systems' characteristics will make software engineering evolve one more time to tackle and address the social era's challenges and issues, respectively.

Software is crafted by engineers, according to stakeholders, and for end-users. This interplay of people is by definition an organizational social structure (OSS). Conway’s law postulates that end-products (software, in our case) mimic the OSS that produced them. However, there is no systematic way for software engineering practitioners to choose and support the OSS best fitting their problem. In this article we discuss the state-of-the-art of OSSs, and provide mechanisms to ease OSS-related decisions in software engineering (e.g. choosing the OSS best fitting the development problem at hand). Our data supports two conclusions. First, software engineering has concentrated on building software by means of project teams alone, yet these are merely one of thirteen OSS flavors observable in literature. Second, another emerging OSS should be explored for the purpose of building software: social networks. This article represents a first attempt to explore OSS-centric software engineering, that is, engineering software by choosing and supporting the OSS best fitting the problem at hand, rather than relying univocally on project teams.

International Journal of Human-Computer Studies, 2008

XX Brazilian Symposium on Software Quality

Context: It is common for a software project to incur technical debt (TD) during its development. It can impact several artifacts produced throughout the software development process. Therefore, it is necessary to carry out management actions to find a balance between the benefits of incurring it and the effects of its presence. However, so far, much of the attention has been given only to discussions relating TD to coding issues. This is a worrying scenario because other types of debt can also have impactful, or even worse, consequences on projects. Aims: This study elaborates on the need to consider other issues of the development process and not just the source-code when investigating the TD phenomenon. Method: We analyze responses from 653 practitioners concerning TD causes, effects, prevention, reasons for nonprevention, repayment, and reasons for non-repayment and investigate whether these TD management elements are related to coding or to other software development issues. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the big picture we draw. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, TD management, and the organization are also common. Lastly, we present a hump diagram that, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. Conclusion: The results shed light on other concerns beyond code that the research community and practitioners need to be aware of.

Journal of Systems and Software, 2015

There exists no generally accepted theory in software engineering, and at the same time a scientific discipline needs theories. Some laws, hypotheses and conjectures exist, but yet no generally accepted theory. Several researchers and initiatives emphasize the need for theory in the discipline. The objective of this paper is to formulate a theory of software engineering. The theory is generated from empirical observations of industry practice, including several case studies and many years of experience in working closely between academia and industry. The theory captures the balancing of three different intellectual capitals: human, social and organizational capitals, respectively. The theory is formulated using a method for building theories in software engineering. It results in a theory where the relationships between the three different intellectual capitals are explored and explained. The theory is illustrated based on an industrial case study, where it is shown how decisions made in industry practice are explainable with the formulated theory, and the consequences of the decisions are made explicit. Based on the positive results, it is concluded that the theory may have a good explanatory power, although more evaluations are needed.

Journal of Software Engineering Research and Development

Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for non-repayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and non-coding issues of the software development process. Results: Coding issues are commonly related to the investigated elements b...

J. Syst. Softw., 2021

Architectural technical debt in software-intensive systems is a metaphor used to describe the ‘‘big’’ design decisions (e.g., choices regarding structure, frameworks, technologies, languages, etc.) that, while being suitable or even optimal when made, significantly hinder progress in the future. While other types of debt, such as code-level technical debt, can be readily detected by static analyzers, and often be refactored with minimal or only incremental efforts, architectural debt is hard to be identified, of wide-ranging remediation cost, daunting, and often avoided. In this study, we aim at developing a better understanding of how software development organizations conceptualize architectural debt, and how they deal with it. In order to do so, in this investigation we apply a mixed empirical method, constituted by a grounded theory study followed by focus groups. With the grounded theory method we construct a theory on architectural technical debt by eliciting qualitative data ...

Americas Conference on Information Systems, …, 2000

This chapter explores patterns of social and technological interaction that emerge in free/open source software development (F/OSSD) projects found in different research and development communities. F/OSSD is a relatively new way for building and deploying large software systems on a global basis, and differs in many interesting ways from the principles and practices traditionally advocated for software engineering. Hundreds of F/OSS systems are now in use by thousands to millions of end-users, and some of these F/OSS systems entail hundreds-of-thousands to millions of lines of source code. So what's going on here, and how are F/OSSD processes that are being used to build and sustain these projects different?