Technical debt interest assessment

Martini, Antonio; Vajda, Simon; Vasa, Rajesh; Jones, Allan; Abdelrazek, Mohamed; Grundy, John; Bosch, Jan

doi:10.1145/3120459.3120469

Cited by 7 publications

(2 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…TD gained relevance among the SE community [54], as scrutiny of systems' quality has become more pronounced [3]. They have approached specific procedures to handle it in software factories [57,71], how it affects (and is affected by) agile practices [33,43], how developers approach it [19,28,75] what are the "common beliefs" about it [11], and how developers' attitudes increase or decrease its existence [3,20].…”

Section: Technical Debtmentioning

confidence: 99%

“…Quantitative, closed-option surveys have been used in both disciplines related to this study (SE and OR). On the one hand, SE has extensively applied this methodology to address different aspects of TD, especially when aiming to uncover the developers' perspectives or knowledge about this topic [10,11,28,33,43,57,63]. On the other hand, OR has also used surveys (both quantitative and qualitative) as methodologies on a myriad of topics [1,2,60,67].…”

Section: Survey Constructionmentioning

confidence: 99%

See 1 more Smart Citation

On technical debt in mathematical programming: An exploratory study

Vidoni

Cúnico

2022

Math. Prog. Comp.

View full text Add to dashboard Cite

The Technical Debt (TD) metaphor describes development shortcuts taken for expediency that cause the degradation of internal software quality. It has served the discourse between engineers and management regarding how to invest resources in maintenance and extend into scientific software (both the tools, the algorithms and the analysis conducted with it). Mathematical programming has been considered ‘special purpose programming’, meant to program and simulate particular problem types (e.g., symbolic mathematics through Matlab). Likewise, more traditional mathematical programming has been considered ‘modelling programming’ to program models by providing programming structures required for mathematical formulations (e.g., GAMS, AMPL, AIMMS). Because of this, other authors have argued the need to consider mathematical programming as closely related to software development. As a result, this paper presents a novel exploration of TD in mathematical programming by assessing self-reported practices through a survey, which gathered 168 complete responses. This study discovered potential debts manifested through smells and attitudinal causes towards them. Results uncovered a trend to refactor and polish the final mathematical model and use version control and detailed comments. Nonetheless, we uncovered traces of negative practices regarding Code Debt and Documentation Debt, alongside hints indicating that most TD is deliberately introduced (i.e., modellers are aware that their practices are not the best). We aim to discuss the idea that TD is also present in mathematical programming and that it may hamper the reproducibility and maintainability of the models created. The overall goal is to outline future areas of work that can lead to changing current modellers’ habits and assist in extending existing mathematical programming (both practice and research) to eventually manage TD in mathematical programming.

show abstract