A Longitudinal Study of Identifying and Paying Down Architecture Debt

Nayebi, Maleknaz; Cai, Yuanfang; Kazman, Rick; Ruhe, Guenther; Feng, Qiong; Carlson, Chris; Chew, Francis

doi:10.1109/icse-seip.2019.00026

Cited by 18 publications

(10 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Discussion: Cai et al [34] argues that number of introduced bugs per commit is not a measure of code comprehension. In their case study, defect rates shot up after refactoring precisely because (a) developers now understood the code better so (b) they were willing to make more changes so (c) they introduced more bugs.…”

Section: Code Understandingmentioning

confidence: 98%

The Changing Nature of Computational Science Software

Tu¹,

Agrawal²

2020

Preprint

View full text Add to dashboard Cite

How should software engineering be adapted for Computational Science (CS)? If we understood that, then we could better support software sustainability, verifiability, reproducibility, comprehension, and usability for CS community. For example, improving the maintainability of the CS code could lead to: (a) faster adaptation of scientific project simulations to new and efficient hardware (multicore and heterogeneous systems); (b) better support for larger teams to co-ordinate (through integration with interdisciplinary teams); and (c) an extended capability to model complex phenomena.In order to better understand computational science, this paper uses quantitative evidence (from 59 CS projects in Github) to check 13 published beliefs about CS. These beliefs reflect on (a) the nature of scientific challenges; (b) the implications of limitations of computer hardware; and (c) the cultural environment of scientific software development. What we found was, using this new data from Github, only a minority of those older beliefs can be endorsed. More than half of the pre-existing beliefs are dubious, which leads us to conclude that the nature of CS software development is changing.Further, going forward, this has implications for ( 1) what kinds of tools we would propose to better support computational science and (2) research directions for both communities.

show abstract

Section: Code Understandingmentioning

confidence: 98%

The Changing Nature of Computational Science Software

Tu¹,

Agrawal²

2020

Preprint

View full text Add to dashboard Cite

show abstract

“…While the topic of how to detect architecture flaws and use this information to refactor architectures is beyond the scope of this paper, we have dealt with this in other work, e.g. [39], [64], [58], [104], [105].…”

Section: Findingmentioning

confidence: 99%

On the Relationship Between Organizational Structure Patterns and Architecture in Agile Teams

Tamburri

Kazman²,

Fahimi³

2023

IIEEE Trans. Software Eng.

Self Cite

View full text Add to dashboard Cite

Forming members of an organisation into coherent groups or teams is an important issue in any large-scale software engineering endeavour, especially so in agile software development where teams rely heavily on self-organisation and organisational flexibility. But is there a recurrent organisational structure pattern in agile software engineering teams? and if so what does that pattern imply, in terms of software architecture quality? We address these questions using mixed-methods research in industry featuring interviews, surveys, and Delphi studies of real agile teams. In our study of 30 agile software teams we found that, out of seven organisational structure patterns that recur across our dataset, a single organisational pattern occurs over 37% of the time. This pattern: (a) reflects young communities (1-12 months old); (b) disappears in established ones (13+ months); and (c) reflects the highest number of architecture smells reported. Finally, we observe a negative correlation between a proposed organisational measure and architecture smells. On the one hand, these insights may serve to aid architects in designing not only their architectures but also their communities to best support their co-evolution. On the other hand, we observe that organisational structures in software engineering influence much more than simply software architectures, and we expect our results to lay the foundations of more structured and rigorous approaches to organisational structure studies and use in software engineering research and practice.

show abstract

“…The term technical debt was first introduced in 1992 by Ward Cunningham [12] who was the first to coin the metaphor that represents "not-quite-right code" as a form of debt in a software system. Although Cunningham only called this "debt" initially, the term Technical Debt gradually gained broad acceptance [13], [14]; it now refers not only to impediments in the code but also in the architecture [15], [16], test [17] and social structures [18] involved in the development of software systems [19]. For instance, according to Ernst et al [20], architectural decisions are the most important source of technical debt.…”

Section: Related Work and Backgroundmentioning

confidence: 99%

Worst Smells and Their Worst Reasons

Falessi

Kazman

2021

2021 IEEE/ACM International Conference on Technical Debt (TechDebt)

Self Cite

View full text Add to dashboard Cite

Code bad smells are symptoms of poor design and implementation. There are several well-known smell types, such as large classes (aka God classes), code clones, etc. and they have been shown to lead to technical debt and hence to decrease code maintainability. Quality gates are a recent technology that prevents the automatic acceptance of push requests of code commits that have been identified as containing certain smells. However, it is a challenging activity to decide which smells should be included in the quality gate, as developers may choose to optimize short term benefits like time to market over long term benefits like maintainability. But some smells appear to provide no benefit to developers whatsoever and hence such smells should always be avoided. The aims of this paper are: 1) to identify "worst smells", i.e., bad smells that never have a good reason to exist, 2) to determine the frequency, change-proneness, and severity associated with worst smells, and 3) to identify the "worst reasons", i.e., the reasons for introducing these worst smells in the first place. To achieve these aims we ran a survey with 71 developers. We learned that 80 out of 314 catalogued code smells are "worst"; that is, developers agreed that these 80 smells should never exist in any code base. We then checked the frequency and change-proneness of these worst smells on 27 large Apache opensource projects. Our results show insignificant differences, in both frequency and change proneness, between worst and non-worst smells. That is to say, these smells are just as damaging as other smells, but there is never any justifiable reason to introduce them. Finally, in follow-up phone interviews with five developers we confirmed that these smells are indeed worst, and the interviewees proposed seven reasons for why they may be introduced in the first place. By explicitly identifying these seven reasons, project stakeholders can, through quality gates or reviews, ensure that such smells are never accepted in a code base, thus improving quality without compromising other goals such as agility or time to market.

show abstract

A Longitudinal Study of Identifying and Paying Down Architecture Debt

Cited by 18 publications

References 29 publications

The Changing Nature of Computational Science Software

The Changing Nature of Computational Science Software

On the Relationship Between Organizational Structure Patterns and Architecture in Agile Teams

Worst Smells and Their Worst Reasons

Contact Info

Product

Resources

About