Do practitioners intentionally repay their own Technical Debt and why?

The impact of Technical Debt (TD) on software maintenance and evolution is of great concern, but recent evidence shows that a considerable amount of TD is fixed by the same developers who introduced it; this is termed self-fixed TD. This characteristic of TD management can potentially impact team dynamics and practices in managing TD. However, the initial evidence is based on low-level source code analysis; this casts some doubt whether practitioners repay their own debt intentionally and under what circumstances. To address this gap, we conducted an online survey on 17 well-known Java and Python open-source software communities to investigate practitioners’ intent and rationale for self-fixing technical debt. We also investigate the relationship between human-related factors (e.g., experience) and self-fixing. The results, derived from the responses of 181 participants, show that a majority addresses their own debt consciously and often. Moreover, those with a higher level of involvement (e.g., more experience in the project and number of contributions) tend to be more concerned about self-fixing TD. We also learned that the sense of responsibility is a common self-fixing driver and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors. The findings in this paper can lead to improving TD prevention and management strategies

Technical Debt: An empirical investigation of its harmfulness and on management strategies in industry

Background: In order to survive in today\u27s fast-growing and ever fast-changing business environment, software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process.Objective: The overarching goal of this Ph.D. thesis is twofold. The first goal is to empirically study and understand in what way and to what extent, TD influences today’s software development work, specifically with the intention to provide more quantitative insight into the field. Second, to understand which different initiatives can reduce the negative effects of TD and also which factors are important to consider when implementing such initiatives.Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, analysis of documents, correlation analysis, and statistical tests. In seven of the eleven studies included in this Ph.D. thesis, a combination of multiple research methods are used to achieve high validity.Results: We present results showing that software suffering from TD will cause various negative effects on both the software and the developing process. These negative effects are illustrated from a technical, financial, and a developer’s working situational perspective. These studies also identify several initiatives that can be undertaken in order to reduce the negative effects of TD.Conclusion: The results show that software developers report that they waste 23% of their working time due to experiencing TD and that TD required them to perform additional time-consuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on daily software development work and that TD has negative effects on several different software quality attributes. Further, the results show that TD reduces developer morale. Moreover, the findings show that intentionally introducing TD in startup companies can allow the startups to cut development time, enabling faster feedback and increased revenue, preserve resources, and decrease risk and thereby contribute to beneficial\ua0effects. This study also identifies several initiatives that can be undertaken in order to reduce the negative effects of TD, such as the introduction of a tracking process where the TD items are introduced in an official backlog. The finding also indicates that there is an unfulfilled potential regarding how managers can influence the manner in which software practitioners address TD

Managing Technical Debt in Agile Software Development Projects

One of the key reasons that agile software development methods have gained popularity in recent years is because they enable organizations to produce software quickly to meet the needs of various stakeholders. However, this focus on delivering software quickly often encourages practitioners to incur technical debt – design or implementation constructs that are expedient in the short term but set up a technical context that can make future changes more costly or impossible. Worldwide, technical debt is estimated to be a trillion-dollar problem. This has prompted significant interest from both researchers and practitioners. In this dissertation, I present two essays that advance our knowledge of the causes of technical debt in agile software development projects and that offer potential solutions to manage the most important of these causes of technical debt. In my first essay, I conduct a ranking-type Delphi study of information technology (IT) project managers and software developers to identify and prioritize the most important causes of technical debt in agile software development projects. The findings from this study provide a verified list of 55 causes of technical debt in agile software development projects and offer 13 potential techniques to manage the causes of technical debt that were most important to the IT project managers and software developers in this study. In my second essay, I conduct a randomized experiment to examine the impact of software developers’ construal level, a cognitive process, on the unintentional accumulation of technical debt in software development projects. The findings from this experiment suggest that software developers at a high construal level are more likely to focus on developing the architecture or design than software developers at a low construal level. Collectively, the findings from these two essays deepen our understanding of the intentional and unintentional causes of technical debt in agile software development projects. Further, the findings offer potential techniques to manage the most important causes of technical debt for IT project managers and software developers

Software practitioners? point of view on technical debt payment

Context: Technical debt (TD) payment refers to the activity of expending maintenance effort and resources to make up for the effects of previous technical compromises. Aims: To investigate if software practitioners have paid debt items off in their projects, the practices that have been used for paying off debt items, and the issues that hamper the implementation of these practices. Method: We analyze 653 responses collected by surveying practitioners from six countries about TD payment. Results: Practitioners have not paid off TD items in most cases. We identified 27 reasons for not paying off those items and 32 payment-related practices. Practices are mainly related to internal quality issues, while reasons for not paying TD off are mostly associated with planning and management issues. Lastly, we identified relationships between practices and between reasons, indicating that both can appear in combination. Conclusion: . We use different views to consolidate the set of information on TD payment, extending the conceptual model for TD and organizing the set of practices and reasons into a TD payment map. We believe that the model and the map can support practitioners in planning their TD payment strategy. (c) 2022 Elsevier Inc. All rights reserved

Financial model for private finance initiative projects applied to school buildings

Private Finance Initiative (PFI) has become a major procurement method in the UK and worldwide. The number of signed PFI deals is growing, but competition is restricted to those companies that are able to afford the initial investment. The bidding cost of PFI projects are high, and bidding companies are not compensated if the client does not award them the project. This is the reason behind several recent high-profile tender xvithdra« als. and is considered a major barrier for private companies wanting to take part in the bidding process. There is an obvious need for a tool to enable construction organizations to participate in PFI projects; one that can support these organizations in a decision-making process that is compatible with their project selection strategies, and will allow them to bid for PFI projects with clearer goals and reduced costs. A computer-based financial model was developed to predict the cost and cash flow of PFI projects, enabling project teams to assess investment decisions at the tendering stage. The proposed model consists of four modules to identify the required building area, predict the construction cost, distribute the occupancy cost, and predict the cash flow of the project. The output of the model provides the project investment results, such as the Net Present Value (NPV), Internal Rate of Return (IRR), Debt Service Coverage Ratio (DSCR), payback period and investment growth ratio. The model can predict the unitary payment but also allows the user to define the unitary payment. The reports of the model contain the cash flow and investment ratio for both types of unitary payment. The model attempts to provide the information required to assess the feasibility and affordability of the project. It gives the private sector the chance to assess the project before they spend unrecoupable funds on the project. It allows the public sector to determine the project cost, cash flow, unitary charge, and provide the information to be used for the Public Sector Comparator. The data required for the development of the model was collected from different sources. The model was initially developed on spreadsheet software: the final version was transformed into a web-based model using the Hypertext Preprocessor (PHP) and Javascript programming languages. The completed model was then sent to many practitioners for validation and assessment of both the concept and numerical application. The responses received show the valuable role the model could play in PFI projects.Ministry of Higher Education, Saudi Arabi

Essentials of forensic accounting

https://egrove.olemiss.edu/aicpa_guides/2728/thumbnail.jp