Technical Debt: From Metaphor to Theory and Practice

Kruchten, Philippe; Nord, Robert L.; Özkaya, Ipek

doi:10.1109/ms.2012.167

Cited by 528 publications

(349 citation statements)

References 2 publications

Supporting

Mentioning

301

Contrasting

Unclassified

Order By: Relevance

“…Technical debt is a metaphor originally referring to "not quite right code which we postpone making it right" (Cunningham 1992) but that since has expanded to include a spectrum of issues from bad coding to architectural issues (Kruchten et al 2012) The system was originally designed for a single customer. Additionally, the development in the previous organization had occurred within strict deadlines.…”

Section: Significant Technical Debtmentioning

confidence: 99%

Large-scale agile transformation at Ericsson: a case study

et al. 2018

View full text Add to dashboard Cite

Many large organizations are adopting agile software development as part of their continuous push towards higher flexibility and shorter lead times, yet few reports on large-scale agile transformations are available in the literature. In this paper we report how Ericsson introduced agile in a new R&D product development program developing a XaaS platform and a related set of services, while simultaneously scaling it up aggressively. The overarching goal for the R&D organization, distributed to five sites at two continents, was to achieve continuous feature delivery. This single case study is based on 45 semistructured interviews during visits at four sites, and five observation sessions at three sites. We describe how the organization experimented with different set-ups for their tens of agile teams aiming for rapid end-to-end development: from component-based virtual teams to totally cross-functional, cross-component, cross-site teams. Moreover, we discuss the challenges the organization faced and how they mitigated them on their journey towards continuous and rapid software engineering. We present four lessons learned for large-scale agile transformations: 1) consider using an experimental approach to transformation, 2) consider implementing the transformation step-wise in complex large-scale settings, 3) team inter-changeability can be limited in a complex large-scale product -specialization might be needed, and 4) not using a common agile framework for the whole organization, in combination with insufficient common trainings and coaching may lead to a lack of common direction in the agile implementation. Further in-depth case studies on large-scale agile transformations, on customizing agile to large-scale settings, as well as on the use of scaling frameworks are needed.

show abstract

Section: Significant Technical Debtmentioning

confidence: 99%

Large-scale agile transformation at Ericsson: a case study

et al. 2018

View full text Add to dashboard Cite

show abstract

“…As a form of technical debt (Cunningham 1993), they could hinder the comprehensibility and maintainability of software systems (Kruchten et al 2012). An example of code smell is the God Class, a large and complex class that centralizes the behavior of a portion of a system and only uses other classes as data holders.…”

Section: Introductionmentioning

confidence: 99%

On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation

et al. 2017

View full text Add to dashboard Cite

Code smells are symptoms of poor design and implementation choices that may hinder code comprehensibility and maintainability. Despite the effort devoted by the research community in studying code smells, the extent to which code smells in software systems affect software maintainability remains still unclear. In this paper we present a large scale empirical investigation on the diffuseness of code smells and their impact on code change-and fault-proneness. The study was conducted across a total of 395 releases of 30

show abstract

“…A further line of research concerns the consequences of making early programming decisions on a purely pragmatic basis (e.g. in order to get the system working); it has been shown that such short cuts create "Technical Debt" on which interest will accrue in the form of error and maintenance costs throughout the lifecycle of the software product (Kruchten et al, 2012).…”

Section: Is Confirmation Holismmentioning

confidence: 99%

Epistemic Opacity, Confirmation Holism and Technical Debt: Computer Simulation in the Light of Empirical Software Engineering

Newman

2016

IFIP Advances in Information and Communication Technology

View full text Add to dashboard Cite

The output of a simulation model does not, prima facie, appear to have an objective status comparable with data captured by observation or experiment. Counter to this Winsberg, Humphreys and others emphasise parallels between experiment and simulation in practices which are said to "carry with them their own credentials" (Winsberg, 2010). Humphreys holds that that the physical implementation of computer models places constraints on simulation methods not present in traditional mathematics, creating essential epistemic opacity. By this he means that it is impossible for a cognitive agent, given its characteristics, to know all of the epistemically relevant elements of a computational process. Humphreys views essential epistemic opacity as reflecting the limitations not of the simulation method itself but of the human agent, and thus as evidence for a "non-anthropocentric epistemology" recognising computational tools as a superior epistemic authority.The possibility of testing a highly parameterised simulation model via the hypothetico-deductive method can indeed be open to doubt; moreover empirical measurements are often not available on the scale needed to evaluate model outputs. Even were appropriate data available, Lenhard & Winsberg (2010) argue that climate simulation models face epistemological challenges associated with a novel kind of "confirmation holism": it is impossible to locate the sources of the failure of any complex simulation to match known data, so that it must stand or fall as a whole. This is because of three interrelated characteristics which they regard as intrinsic to the practice of complex systems modelling -"fuzzy modularity", "kludging" and "generative entrenchment". In "fuzzy modularity", different modules simulating different parts of the complex system are in continual interaction, thus it is difficult to define clean interfaces between the components of the model.  A kludge is an inelegant, 'botched together' piece of program, very complex, unprincipled in its design, ill-understood, hard to prove complete or sound and therefore having unknown limitations, and hard to maintain or extend.  Generative entrenchment refers to the historical inheritance of hard-to-alter features from predecessor models. Is confirmation holism(1) essential to and unavoidable in complex systems modelling?(2) embedded in specific disciplinary practices of climate science? or (3) does it exemplify a failure to observe, recognise and apply available and wellestablished sound Software Engineering practices when developing simulation software (as promoted, for example, by the Sustainable Software Institute)?Belief in the essential epistemic opacity of computational science points to (1) but we shall argue for (3) on two main grounds.

show abstract

Technical Debt: From Metaphor to Theory and Practice

Cited by 528 publications

References 2 publications

Large-scale agile transformation at Ericsson: a case study

Large-scale agile transformation at Ericsson: a case study

On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation

Epistemic Opacity, Confirmation Holism and Technical Debt: Computer Simulation in the Light of Empirical Software Engineering

Contact Info

Product

Resources

About