Talk:Technical debt

Value judgment phrase

The phrase "the architecture of a large software system is designed and developed too hastily" makes a (possibly unwarranted) value judgement about software management practices. Although I am in favor of clean code and good documentation (etc), I also recognize that there may be situations where they can and should be set aside (temporarily) for the purpose of releasing code. This is not inconsistent with the notion of debt; sometimes taking on debt is appropriate...

Technical debt is not the same as design debt. Technical debt is the general concept and can apply to low-level coding issues. — Preceding unsigned comment added by 217.210.143.114 (talk) 08:31, 17 March 2013 (UTC)

I think the article should mentioned the keyword 'refactoring'. In some good words, mention that 'refactoring' is a usual outcome of technical debt (in software development). —Preceding unsigned comment added by Evoluzion (talk • contribs) 23:24, 29 January 2010 (UTC)

Wow, this is an awesome concept, I'm going to start using it more often in the analysis and budgets of the systems i work with :) —Preceding unsigned comment added by 124.169.201.55 (talk) 11:54, 25 May 2010 (UTC)

Technical debt is code, systems setup, etc what evolution wants to kill, but the debt refuses to die because of people want to keep it living that way. — Preceding unsigned comment added by 151.193.120.17 (talk) 16:04, 25 October 2012 (UTC)

Paying off technical debt

Very interesting and increasingly important topic. Could be helpful to clarify what is meant by:

"'Interest payments' are both in the necessary local maintenance and the absence of maintenance by other users of the project.

Sgb1960 (talk) 12:17, 9 March 2015 (UTC)

Not all Technical Debt is the result of poor design

I think the article is very misleading in too narrowly scoping technical debt to things that are the result of poor design. Not all technical debt is "work that needs to be done before a particular job can be considered complete or proper". The article itself eludes to this: '"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project.' So technical debt can apply to any system that requires maintenance of any kind.

All systems have technical debt, even those that are perfectly designed. There will always be maintenance involved, either at the hardware or software level, and if you fail to acknowledge that, then you fail to realize how different architectures minimize long term technical debt.

Technical debt generally also includes the cost of maintaining and supporting an instance of a system. The software could be complete and properly designed, but regardless, you still have technical debt. If the system is designed such that a new instance of the application is needed for each client, then your technical debt is multiplied by the number of customer instances you have to standup.

Often SaaS approach tries to minimize that kind of technical debt by using a centralized multi-tenant system so that long term maintenance/support does not grow significantly in relation to the number of users/customers. This is also the reason(not always justifiable) that many business are moving to the cloud, to decrease the technical debt of maintaining hardware and operating system locally, so that they only need to maintain the instance of the application they are running on the cloud system.

199.44.231.8 (talk) 21:01, 19 May 2015 (UTC)

You make some good points; you're welcome to edit them in if you can find some WP:RS. Reify-tech (talk) 00:00, 20 May 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 4 external links on Technical debt. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20120621171342/http://blog.techdebt.org:80/resources-links/67/ward-cunningham-interview-about-technical-debt-sqale-agile to http://blog.techdebt.org/resources-links/67/ward-cunningham-interview-about-technical-debt-sqale-agile
• Added archive https://web.archive.org/20120717083235/http://blog.techdebt.org:80/interviews/156/interview-with-philippe-kruchten-on-technical-debt-rup-ubc-decision-process-architecture to http://blog.techdebt.org/interviews/156/interview-with-philippe-kruchten-on-technical-debt-rup-ubc-decision-process-architecture
• Added archive https://web.archive.org/20121129073247/http://blog.techdebt.org:80/interviews/189/technical-debt-interview-with-ipek-ozkaya-on-technical-debt-sei-ieee-software-architecture-agile to http://blog.techdebt.org/interviews/189/technical-debt-interview-with-ipek-ozkaya-on-technical-debt-sei-ieee-software-architecture-agile
• Added archive https://web.archive.org/20120714053317/http://blog.techdebt.org:80/interviews/118/interview-with-jean-louis-letouzey-on-technical-debt-and-sqale to http://blog.techdebt.org/interviews/118/interview-with-jean-louis-letouzey-on-technical-debt-and-sqale

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:12, 23 February 2016 (UTC)

Suggested links to remove citation Maintenance Tag

This link could be used to support several of the tech-debt reasons: http://www.ontechnicaldebt.com/uncategorized/the-causes-of-technical-debt-do-not-exist-in-a-vacuum/ Then the tag can be removed. Mediation4u ^(chat) _{nb: editing is fun} 10:54, 28 March 2017 (UTC)

"Technical Debt" Not Defined.

This is odd: the article does not define "technical debt."

We are told that it is a concept which reflects A, can be compared to B, and is used in C. A good deal else is said about it.

Nowhere is it said what it is or is claimed to be.

David Lloyd-Jones (talk) 12:05, 20 April 2019 (UTC)

the definition of tech debt isn't correct

> concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer

tech debt isn't always choosing the easier (limited) solution. it could be incurred for many reasons such as legacy or outdated system, poor design practices, lousy code structure, etc. — Preceding unsigned comment added by Ucalgary26 (talk • contribs) 06:31, 2 February 2020 (UTC)

The Contribution of Cultural Practices in Software Engineering on Technical Debt and Relevance in Saudi Arabia

Abstract The concept of technical debt (TD) in software engineering has garnered much interest among academics due to its impact on software development. This research aims to investigate the cultural traditions of software engineering in Saudi Arabia and their influence on technical debt (TD). Through a review of 28 studies and articles, the study seeks to determine the impact of unique cultural factors in Saudi Arabian organizations on technical debt (TD). The results demonstrate that cultural norms, such as indulgence in ambiguity and avoidance of ambiguity, have both positive and negative effects on technical debt. Moreover, the national cultural patterns in the software industry may either facilitate or obstruct the development of both planned and unplanned technical debt, depending on one's perspective.

Keywords: Technical Debt (TD), Cultural practices, Saudi Arabia, Software Development

1. Introduction Ward Cunningham's (1992) invention of the term "Technical Debt" (TD) has been widely used in the software engineering field. It balances the short-term value against the inner software quality in order to promote the proper development of the software system. This is a simple method for documenting and communicating common software process issues. Technical debt (TD) defines outstanding development tasks as a type of debt that provides a project with a short-term benefit, typically in the form of higher efficiency or faster software release cycles, but must be repaid with interest at a later stage in the development procedure (Alves et al., 2016). Technical Debt (TD) has recently gained prominence in the field of software engineering. Organizational culture has an impact on and influences everything an institution does. Managers are also produced, and managers shape culture (Schein, 2016). Fortunately, for certain goals, such as improving technical debt management, it is critical to investigate every available culture. All that is required to make cultures more receptive to technological debt management initiatives is knowledge of how to modify cultures. Cultural development issues may jeopardize software development. The software industry is the third-largest producer in Saudi Arabia, so it is critical to understand how Saudi software professionals perceive and manage Technical Debt (TD). Both the Saudi government and the software industry stand to benefit greatly from increased software development. The majority of previous research and others looked into the technical, economic, and institutional aspects of Technical Debt (TD) (Li et al., 2015; Ampatzoglou et al., 2016; Besker et al., 2018). The cultural aspects of Technical Debt (TD) have received little attention in the literature to date. The purpose of this research is to discover cultural norms in software engineering and how they affect technical debt in Saudi Arabia.

2. Overview and Background 2.1 Definition of Technical Debt Ward Cunningham (1992) coined the term "technical debt" to describe the problem of meeting a delivery deadline by modifying and compromising a product. He also explained how the consequences were comparable to those caused by incurring debt. Cunningham observed that technological debt must typically be repaid, whereas poor asset management may result in a complete shutdown when the cost and impact of modifications (or lack thereof) became intolerable. Later, the term "technical debt" was revisited several times, frequently to broaden what Cunningham had previously articulated for all instances that were relevant when classifying its features. Academics have largely accepted Steve McConnell's (2007) formulation, which distinguishes between the intentional and unintentional accumulation of technical debt. 2.2 Approaches and Practices of Software Development A The Agile Manifesto reflects a software development approach that emphasizes an environment where resources are limited and the need for unpredictability is high (Beck et al., 2001). Agile processes have received widespread support, leading to their widespread use and investigation (Dingsyr et al., 2012). There are numerous approaches to implementing agile practices, with Extreme Programming (XP) and Scrum (Schwaber & Beedle, 2002) being two of the most extensively researched (Dyb et al., 2008). The Extreme Programming (XP) approach's 12 practices are viewed as the primary means of implementing the agile manifesto's principles. For example, the On-Site Customer Practice requires the Customer to be available at all times. This method reduces feedback time because developers can quickly solicit customer feedback and resolve issues, resulting in less expensive rebalancing (Beck, 2004). As a supplement, the Scrum methodology defines procedures and process artifacts. Thus, the Iteration Review process, which requires concluding each production iteration with such a meeting in which the Product Manager serves as the customer representative and provides input, is the primary method of obtaining client feedback. 2.3 Technical Debt in Saudi Arabia There is no agreement among stakeholders in Saudi Arabia and elsewhere on the cost-benefits of software technical debt. On the one hand, critics claimed that software technical debt was detrimental to business operations because rigid software architectures became less capable of responding to future developments (Alfayez et al., 2020; Alves et al., 2016). This viewpoint was based on the notion that an excessive accumulation of software technical debt could result in unmanageable and rigid systems, as well as a lack of motivation to address coding issues (Alfayez et al., 2020). The Almabani General Construction Company in Jeddah demonstrated the link between rigid systems, legacy systems, and the possibility of Technical Debt (TD) accumulation (Veryant, 2022). The CodeScene (2022) report, which claimed that software engineers lost 18% of their worktime and 42% of their weekly hours fixing problems caused by technical debt, backed up Alfayez et al concerns’ (2020). Thus, given Saudi Arabia's technological constraints and a lack of trained personnel (Hayek et al., 2019), the software industry's massive accumulation of technical debt was unsustainable.

3. Materials and Methods 3.1 Search Strategy Systematic reviews, which have a lower risk of bias and greater dependability than traditional/ad hoc reviews, are critical for assessing the state of the art in Technical Debt (TD) research (Brings et al., 2015). SLR is also a well-established approach in software research (Mumtaz et al., 2022). One of the most important aspects of a systematic review is determining the research methodology for obtaining material from academic databases such as IEEE and Web of Science. The three most commonly used search methods are manual, automatic, and snowballing (Bogner et al., 2021). While manual searches focus on previously published articles, automatic searches are guided by a pre-defined search term. In The three strategies were used in this case to reduce the number of missing documents. The quasi-gold standard (QSG) approach increased the sensitivity and accuracy of the process (Zhang et al., 2011). Zhang, Babar, and Tell (2011), among others, have demonstrated the quasi-gold standard (QSG) technique's validity in selecting relevant research in software engineering and computer technology. Data were collected from the academic databases ACM Digital Library, Web of Science, Elsevier, IEEE, JSTOR, Taylor and Francis, and Emerald Insight using both automatic and human research techniques. Li et al. (2015) and Lenarduzzi et al. (2021) investigated software technical debt management techniques, tactics, priorities, factors, and tools; their findings aided in the search. The publication period was from 2012 to 2022. Exceptions were made for important papers on technological debt. Seminal papers were defined in this context as research that provided a unique contribution and distinguished arguments on software technical debt in a Saudi Arabian and international context. 3.2 Study Selection Software, technical debt, technology businesses, management, culture, and legacy systems were among the keywords used as a guide for both the automatic and human search processes. To expand the search terms, the Boolean operators and/or were used. For example, combining the search terms "software technical debt" and "Saudi technology businesses" yielded more relevant results. Debt was not used alone because doing so would have revealed irrelevant financial transaction data. Table 1 summarizes the inclusion and exclusion criteria used to guide the literature review process. Table 1 Inclusion and exclusion criteria Criteria Requirement Inclusion Research publications that emphasized software technical debt issues in Saudi Arabia

Articles that investigated monitoring and management of software technical debt, cost-implications, cultural characteristics, and monitoring and management of software technical debt Exclusion Studies that did not focus on software technical debt.

Research that was not relevant to Saudi Arabia.

Duplicate articles and grey literature After using the inclusion and exclusion criteria in conjunction with a successful combination of search phrases, 28 articles were discovered. The screening procedures for the entire text, headline, and abstract eliminated duplicate and non-value-added Technical Debt (TD) studies (see Figure 1). Page et al. (2021) confirmed the inclusion of the PRISMA framework and proposed a method for presenting critical appraisal evidence.

Figure 1 PRISMA diagram illustrating the article selection process Forward and backward snowballing were applied to the 28 articles identified by the PRISMA screening procedure using the parameters outlined by Li et al (2015). An iteration of the snowballing procedure was performed to help ensure the applicability of the retrieved studies. Although no new publications were created as a result of the procedure, one study that was less relevant to Technical Debt (TD) in a Saudi context was dropped. 3.3 Data Extraction and Synthesis Before assigning a score, each investigator who participated in the data extraction procedure read the entire text of each article. The grade indicated how effectively the research addressed the major topics and research questions. After reading the publications, the researchers met to discuss the findings. Articles with higher ratings take precedence. The findings were combined using descriptive quantitative data analysis and thematic analysis of data on Technical Debt (TD) in Saudi Arabia and elsewhere. Thematic analysis is a well-known data analysis technique (Kiger & Varpio, 2020; Vaismoradi et al., 2013). Content analysis, in conjunction with inductive and deductive reasoning, established the basic patterns in monitoring and controlling technical debt in new and legacy software systems. Each theme was assigned a research question. The only issue with theme analysis was the inability to infer causal relationships. Unstandardized theme analysis was also called into question by Nowell, Norris, White, and Moules (2017).

4. Results and Discussion The context of technology adoption in Saudi Arabia demonstrates the impact of culture on software engineering methods. Previously, Information Communications Technology (ICT) use was restricted to government agencies and businesses in high-priority industries such as oil and gas (including Aramco) (Almowanes, 2017). Slow adoption of computing technologies in Saudi Arabia could be attributed to societal acceptance, historical, financial, and cultural factors, as well as the government's concerns about technology and its alleged effects on communications, religion, and national security (Almowanes, 2017; Alshahrani, 2016). The unified theory of acceptance and use of technology (UTAUT), which proposed that user intentions could predict the acceptability of new technologies, behaviors, effort, and performance expectancy (Alshareef & Tunio, 2022), offered an alternative explanation for Information Communications Technology (ICT) adoption disparities (see Figure 2). Given that the model correctly predicted the barriers and facilitators of blockchain system adoption in KSA technology SMEs, it can help predict the risk of Technical Debt (TD) accumulation.

Figure 2 UTAUT theory in the context of software Technical Debt (TD) in KSA Beyond UTAUT, KSA's high levels of collectivism and uncertainty avoidance are cultural impediments to technological advancement (Almowanes, 2017). Almowanes' (2017) concerns about the influence of regional cultures on the adoption of Information Communications Technology (ICT) systems in KSA were consistent with Hofstede's (2022) model. Figure 3 compares uncertainty avoidance in the Kingdom of Saudi Arabia to that in the United States, the United Kingdom, and China. According to the graph, KSA had the lowest levels of indulgence and the highest levels of uncertainty avoidance (Hofstede, 2022). Figure 3 Uncertainty avoidance in the KSA versus other countries of interest The current body of research on the relationship between cultural traits and software engineering practices lends support to the use of Hofstede's model to forecast software practices and the potential danger of Technical Debt (TD) accumulation (Darwish & Henryson, 2019). The study of technology serves as a catalyst for national development and long-term thinking (Cetinguc et al., 2020). A cross-national study involving Sweden, Indonesia, Japan, and China discovered that higher levels of long-term orientation were associated with specific behaviors among software professionals (Darwish & Henryson, 2019). Depending on your point of view, the national cultural patterns of the software industry may help or hinder control of planned and unplanned Technical Debt (TD). Long-term orientation was characterized by high levels of bug monitoring, restructuring, progress measurement, and regular risk assessment of software systems (Darwish & Henryson, 2019). To reduce uncertainty in the countries of interest, the software developers prioritized early design choices, test-first programming, and upfront requirement specification (Darwish & Henryson, 2019). Each of the three conditions could reduce the accumulation of Technical Debt (TD), especially given that workarounds were partially to blame for unplanned Technical Debt (TD) (Griffith et al., 2015; Klinger et al., 2011; Salaou et al., 2021). The findings of Hofstede's model may enable proactive Technical Debt (TD) monitoring in Saudi software firms. However, there aren't enough facts to back up these theories in the Saudi software ecosystem.

5. Conclusion The advent of new technologies has posed a challenge in balancing the trade-off between prices, performance, source code flexibility, and cultural dynamics in host communities. Cultural dynamics, such as masculinity, uncertainty avoidance, individualism, collectivism, indulgence, and long-term orientation, play a crucial role in shaping the impact of Technical Debt (TD) in organizations. In Saudi Arabia, the high level of uncertainty avoidance may result in a slow adoption of intelligent Technical Debt (TD) management methods. However, the benefits of artificial intelligence and machine learning are expected to outweigh the difficulties faced during the initial stages of implementation. Technical debt can arise both intentionally and unintentionally through violations of coding best practices, poor software design, and quick and simple solutions intended to release products to the market or save time and resources. These practices may result in shifting Technical Debt (TD) costs to other stakeholders or repeating them in the future. The interconnected nature of the MENA economies and industries means that the Technical Debt (TD) practices in KSA are relevant and could positively or negatively impact the expansion of the Information Communications Technology (ICT) industry in the region.

References Alfayez, R., Alwehaibi, W., Winn, R., Venson, E., & Boehm, B. (2020). A systematic literature review of technical debt prioritization. Proceedings - 2020 IEEE/ACM International Conference on Technical Debt, TechDebt 2020, 1–10. https://doi.org/10.1145/3387906.3388630 Almowanes, A. (2017). History of Computing in Saudi Arabia- A Cultural Perspective. International Journal of Social Science and Humanity, 7(7). https://doi.org/10.18178/ijssh.2017.7.7.862 Alshahrani, H. A. (2016). A Brief History of the Internet in Saudi Arabia. TechTrends, 60(1), 19–20. https://doi.org/10.1007/s11528-015-0012-5 Alshareef, N., & Tunio, M. N. (2022). Role of Leadership in Adoption of Blockchain Technology in Small and Medium Enterprises in Saudi Arabia. Frontiers in Psychology, 13, 1–11. https://doi.org/10.3389/fpsyg.2022.911432 Alves, N; Mendes, T; Mendonça, M; Spínola, R; Shull, F; Seaman, C. (2016). Identification and Management of Technical Debt: A Systematic Mapping Study. Information and Software Technology, 70, 100 – 121. Ampatzoglou, A., Ampatzoglou, A., Avgeriou, P., Chatzigeorgiou, A., 2016. A financial approach for managing interest in technical debt. Lecture Notes Bus. Inf. Process. 257, 117–133. Besker, T., Martini, A., Bosch, J., 2018. Managing architectural technical debt: a unified model and systematic literature review. J. Syst. Softw. 135, 1–16 Supplement C. Beck, K; Beedle, M; Van Bennekum, A; Cockburn, A; Cunningham, W; Fowler, M; Grenning; Highsmith, J; Hunt, A; Jeffries, R et al. (2001). Manifesto for agile software development. Online, URL: http://agilemanifesto.org/. Beck, K; Andres, C. (2004). Extreme Programming Explained: Embrace Change, Addison-Wesley Professional. Bogner, J., Verdecchia, R., & Gerostathopoulos, I. (2021). Characterizing Technical Debt and Antipatterns in AI-Based Systems: A Systematic Mapping Study. Proceedings - 2021 IEEE/ACM International Conference on Technical Debt, 64–73. https://doi.org/10.1109/TechDebt52882.2021.00016 Brings, J., Salmon, A., & Saritas, S. (2015). Context uncertainty in requirements engineering: Definition of a search strategy for a systematic review and preliminary results. CEUR Workshop Proceedings, 1342, 171–178. Cetinguc, B., Calik, E., & Calisir, F. (2020). The Moderating Effect of Long-Term Orientation on the Relationship Among Human Capital Research, Business Sophistication, and Knowledge & Technology Outputs. In Industrial Engineering in the Digital Disruption Era (pp. 291–296). Springer Berlin Heidelberg. CodeScene. (2022). Business costs of technical debt. 1–15. Darwish, A., & Henryson, A. (2019). How do Cultural Characteristics and Software Engineering Practices Interplay? A Comparative Study Between Indonesia and Sweden. University of Gothenburg and Chalmers University of Technology, 1–15.

 Dingsøyr, T; Nerur, S;  Balijepally, V; Moe, N. (2012). A decade of agile methodologies: towards explaining agile software development, J. Syst. Softw. 85  (6), 1213–1221.

Griffith, I., Taffahi, H., Izurieta, C., & Claudio, D. (2015). A simulation study of practical methods for technical debt management in agile software development. Proceedings - Winter Simulation Conference, 1014–1025. https://doi.org/10.1109/WSC.2014.7019961 Hofstede, G. (2022). Hofstede’s Insights: Saudi Arabia. https://www.hofstede-insights.com/country-comparison/china,saudi-arabia,the-uk,the-usa/ Kiger, M. E., & Varpio, L. (2020). Thematic analysis of qualitative data : AMEE Guide. Medical Teacher, 0(0), 1–9. https://doi.org/10.1080/0142159X.2020.1755030 Lenarduzzi, V., Besker, T., Taibi, D., Martini, A., & Arcelli Fontana, F. (2021). A systematic literature review on Technical Debt prioritization: Strategies, processes, factors, and tools. Journal of Systems and Software, 171, 110827. https://doi.org/10.1016/j.jss.2020.110827 Li, Z., Avgeriou, P., Liang, P., 2015. A systematic mapping study on technical debt and its management. J. Syst. Softw. 101, 193–220. McConnell, S. (2007). Technical debt. Online, URL: http://www.construx.com/10x_ Software_Development/Technical_Debt/ Mumtaz, M., Ahmad, N., Usman Ashraf, M., Alghamdi, A. M., Bahaddad, A. A., & Almarhabi, K. A. (2022). Iteration Causes, Impact, and Timing in Software Development Lifecycle: An SLR. IEEE Access, 10, 65355–65375. https://doi.org/10.1109/ACCESS.2022.3182703 Nowell, L., Norris, J., White, D., & Moules, N. (2017). Thematic Analysis: Striving to Meet the Trustworthiness Criteria. International Journal of Qualitative Methods, 16(1), 1–13. https://doi.org/10.1080/17439760.2016.1262613 Page, M. J., McKenzie, J. E., Bossuyt, P. M., Boutron, I., Hoffmann, T. C., & Mulrow, C. D. (2021). The PRISMA 2020 statement: an updated guideline for reporting systematic reviews. BMJ, 372, 71. Schein, E. (2016). San Francisco: Jossey-Bass. Schwaber, K; Beedle, M. (2002). Agile software development with Scrum, 18 Prentice Hall PTR Upper Saddle River, NJ. Veryant. (2022). Almabani General Contractors: Accounting, finance, invoicing, and asset management software. 1–4. Ward Cunningham. 1992. The WyCash portfolio management system. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA, Vol. Part F1296. 29–30. https://doi.org/10.1145/157710. 157715 Zhou, Y., Xia, Q., Zhang, Z., Quan, M., & Li, H. (2022). Artificial intelligence and machine learning for the green development of agriculture in the emerging manufacturing industry in the IoT platform. Acta Agriculturae Scandinavica Section B: Soil and Plant Science, 72(1), 284–299. https://doi.org/10.1080/09064710.2021.2008482 Eng. Anna (talk) 14:13, 13 February 2023 (UTC)

The Contribution of Cultural Practices in Software Engineering on Technical Debt and Relevance in Saudi Arabia

Abstract The concept of technical debt (TD) in software engineering has garnered much interest among academics due to its impact on software development. This research aims to investigate the cultural traditions of software engineering in Saudi Arabia and their influence on technical debt (TD). Through a review of 28 studies and articles, the study seeks to determine the impact of unique cultural factors in Saudi Arabian organizations on technical debt (TD). The results demonstrate that cultural norms, such as indulgence in ambiguity and avoidance of ambiguity, have both positive and negative effects on technical debt. Moreover, the national cultural patterns in the software industry may either facilitate or obstruct the development of both planned and unplanned technical debt, depending on one's perspective. In addition, the Review revealed that TD was a typical occurrence throughout the software development lifecycle. Despite the paucity of research on the topic in KSA, the existence of TD was deduced from the country’s continued use of legacy software systems (COBOL code and Fortran) by Almabani General Construction and Umm Al-Qura University, both of which are based in Jeddah, the country’s growing demand for software products, KSA’s strategic positioning as a digital hub for the MENA and the GCC, the emergence of local software firms like Intell (Almabani-Veryant, and Saudi Investment Bank- Wincor Nixdorf).

Keywords: Technical Debt (TD), Cultural practices, Saudi Arabia, Software Development

1. Introduction Ward Cunningham's (1992) invention of the term "Technical Debt" (TD) has been widely used in the software engineering field. It balances the short-term value against the inner software quality in order to promote the proper development of the software system. This is a simple method for documenting and communicating common software process issues. Technical debt (TD) defines outstanding development tasks as a type of debt that provides a project with a short-term benefit, typically in the form of higher efficiency or faster software release cycles but must be repaid with interest at a later stage in the development procedure (Alves et al., 2016). Technical Debt (TD) has recently gained prominence in the field of software engineering. Organizational culture has an impact on and influences everything an institution does. Managers are also produced, and managers shape culture (Schein, 2016). Fortunately, for certain goals, such as improving technical debt management, it is critical to investigate every available culture. All that is required to make cultures more receptive to technological debt management initiatives is knowledge of how to modify cultures. Cultural development issues may jeopardize software development. The software industry is the third-largest producer in Saudi Arabia, so it is critical to understand how Saudi software professionals perceive and manage Technical Debt (TD). Both the Saudi government and the software industry stand to benefit greatly from increased software development. The majority of previous research and others looked into the technical, economic, and institutional aspects of Technical Debt (TD) (Li et al., 2015; Ampatzoglou et al., 2016; Besker et al., 2018). The cultural aspects of Technical Debt (TD) have received little attention in the literature to date. The purpose of this research is to discover cultural norms in software engineering and how they affect technical debt in Saudi Arabia. The objectives of the research paper could be achieved by answering the following questions: 1. What specific cultural practices in software engineering can impact technical debt in Saudi Arabia? 2. How do cultural practices in software engineering in Saudi Arabia contribute to the occurrence of technical debt? 3. How do cultural practices in software engineering influence the degree of difficulty in resolving technical debt in Saudi Arabia? 4. How does the framework of TD differ from the criteria in other countries? 1.2 Significance of the research

   This research aims to investigate how cultural practices in software engineering affect the amount of technical debt in Saudi Arabia, in addition to comparing its TD framework with other countries’ criteria. It will analyze the relationship between attitudes, values, and approaches related to software engineering within the Saudi Arabian context and how they contribute to the creation of technical debt. The results of this study could provide valuable insight into how cultural practices in software engineering can help reduce the amount of technical debt in Saudi Arabia.

2. Overview and Background 2.1 Definition of Technical Debt Ward Cunningham (1992) coined the term "technical debt" to describe the problem of meeting a delivery deadline by modifying and compromising a product. He also explained how the consequences were comparable to those caused by incurring debt. Cunningham observed that technological debt must typically be repaid, whereas poor asset management may result in a complete shutdown when the cost and impact of modifications (or lack thereof) became intolerable. Later, the term "technical debt" was revisited several times, frequently to broaden what Cunningham had previously articulated for all instances that were relevant when classifying its features. Academics have largely accepted Steve McConnell's (2007) formulation, which distinguishes between the intentional and unintentional accumulation of technical debt. 2.2 Approaches and Practices of Software Development A The Agile Manifesto reflects a software development approach that emphasizes an environment where resources are limited and the need for unpredictability is high (Beck et al., 2001). Agile processes have received widespread support, leading to their widespread use and investigation (Dingsyr et al., 2012). There are numerous approaches to implementing agile practices, with Extreme Programming (XP) and Scrum (Schwaber & Beedle, 2002) being two of the most extensively researched (Dyb et al., 2008). The Extreme Programming (XP) approach's 12 practices are viewed as the primary means of implementing the agile manifesto's principles. For example, the On-Site Customer Practice requires the Customer to be available at all times. This method reduces feedback time because developers can quickly solicit customer feedback and resolve issues, resulting in less expensive rebalancing (Beck, 2004). As a supplement, the Scrum methodology defines procedures and process artifacts. Thus, the Iteration Review process, which requires concluding each production iteration with such a meeting in which the Product Manager serves as the customer representative and provides input, is the primary method of obtaining client feedback. 2.3 Technical Debt in Saudi Arabia There is no agreement among stakeholders in Saudi Arabia and elsewhere on the cost-benefits of software technical debt. On the one hand, critics claimed that software technical debt was detrimental to business operations because rigid software architectures became less capable of responding to future developments (Alfayez et al., 2020; Alves et al., 2016). This viewpoint was based on the notion that an excessive accumulation of software technical debt could result in unmanageable and rigid systems, as well as a lack of motivation to address coding issues (Alfayez et al., 2020). The Almabani General Construction Company in Jeddah demonstrated the link between rigid systems, legacy systems, and the possibility of Technical Debt (TD) accumulation (Veryant, 2022). The CodeScene (2022) report, which claimed that software engineers lost 18% of their worktime and 42% of their weekly hours fixing problems caused by technical debt, backed up Alfayez et al concerns’ (2020). Thus, given Saudi Arabia's technological constraints and a lack of trained personnel (Hayek et al., 2019), the software industry's massive accumulation of technical debt was unsustainable. 2.4 Software Development Cycle and TD The concept, analysis, designing, implementing, monitoring, integration, and maintenance phases of the software engineering cycle are shown in Table 1. (Randhawa, 2022; Stol & Fitzgerald, 2018). The management of TD, which accumulates as a result of subpar maintenance, design, and implementation, is impacted by the software development life cycle (Aldaeej & Seaman, 2022; Z. Li et al., 2015). In principle, effective software development lifecycle management would lessen the buildup of unplanned TD. Software maintenance, for instance, might assist find code smells that are indicative of TD. Software maintenance, which includes bug repairing and optimizing the software needs, is essential to the control of STDs, according to recent literature (Gijsen, 2020; Xuan et al., 2012). According to this viewpoint, Xuan et al. (2012) suggested using "debt-prone defects to describe the technical debt in software maintenance." Beyond the debt-prone problems, such as tag bugs, reopened bugs, and duplicate bugs, the advice might not be suitable for software development. Table 1: Software development phases Software phases Solutions can be used to help with technical debt Requirement Proper planning and allocation of resources in software development Analysis Identification of vulnerabilities in the software code/legacy system Design Design of a flexible software architecture responsive to future design changes implementation Implementation of agile processes, adoption of SPI standards, and sharing of information Testing Testing software capabilities and limitations Maintenance Bug fixing and resolving code smells

2.5 Code Refactoring The refactoring procedure restructures the software code without altering the software product's basic functioning (Watts & Kidd, 2018). Refactoring software code in a constructive manner decreases TD. 2.6 Version control software Version control systems are computer-based tools that assist software developers in more quickly and intelligently monitoring to source code (Bitbucket, 2022). The importance of the version control system stems from its enhancement of the efficiency and dependability of the software management process (Bitbucket, 2022). A greater use of version control technologies might stop TD from building up. 2.7 Code Smell Software vulnerabilities like hacking and system failures grew as a result of bugs and bad programming. It was clear in Saudi Arabia and North America that the older systems are still susceptible to cyber infiltration. Legacy systems created in the 1950s and 1960s are still used by NASA and other US government entities (Evans et al., 2019; Ahmad, Alkhalil, Altamimi, Sultan, & Khan, 2021). According to Keshta et al., the implementation of ISO/IEC 15504 and the Capability Maturity Model Integration (CMMI) standards can lessen or prevent the accumulation of unplanned TD (2017). The development of unintended TD might be stopped through CMMI and ISO 15504. The computer systems at NASA Jet Propulsion Laboratory have shown how useful CMMI is (Evans et al., 2019). The introduction of the software program improvement (SPI) paradigm can help to reduce TD even further. 3. Materials and Methods 3.1 Search Strategy Systematic reviews, which have a lower risk of bias and greater dependability than traditional/ad hoc reviews, are critical for assessing the state of the art in Technical Debt (TD) research (Brings et al., 2015). SLR is also a well-established approach in software research (Mumtaz et al., 2022). One of the most important aspects of a systematic review is determining the research methodology for obtaining material from academic databases such as IEEE and Web of Science. The three most commonly used search methods are manual, automatic, and snowballing (Bogner et al., 2021). While manual searches focus on previously published articles, automatic searches are guided by a pre-defined search term. In The three strategies were used in this case to reduce the number of missing documents. The quasi-gold standard (QSG) approach increased the sensitivity and accuracy of the process (Zhang et al., 2011). Zhang, Babar, and Tell (2011), among others, have demonstrated the quasi-gold standard (QSG) technique's validity in selecting relevant research in software engineering and computer technology. Data were collected from the academic databases ACM Digital Library, Web of Science, Elsevier, IEEE, JSTOR, Taylor and Francis, and Emerald Insight using both automatic and human research techniques. Li et al. (2015) and Lenarduzzi et al. (2021) investigated software technical debt management techniques, tactics, priorities, factors, and tools; their findings aided in the search. The publication period was from 2012 to 2022. Exceptions were made for important papers on technological debt. Seminal papers were defined in this context as research that provided a unique contribution and distinguished arguments on software technical debt in a Saudi Arabian and international context. 3.2 Study Selection Software, technical debt, technology businesses, management, culture, and legacy systems were among the keywords used as a guide for both the automatic and human search processes. To expand the search terms, the Boolean operators and/or were used. For example, combining the search terms "software technical debt" and "Saudi technology businesses" yielded more relevant results. Debt was not used alone because doing so would have revealed irrelevant financial transaction data. Table 1 summarizes the inclusion and exclusion criteria used to guide the literature review process. Table 2 Inclusion and exclusion criteria Criteria Requirement Inclusion Research publications that emphasized software technical debt issues in Saudi Arabia

Articles that investigated monitoring and management of software technical debt, cost-implications, cultural characteristics, and monitoring and management of software technical debt Exclusion Studies that did not focus on software technical debt.

Research that was not relevant to Saudi Arabia.

Duplicate articles and grey literature After using the inclusion and exclusion criteria in conjunction with a successful combination of search phrases, 28 articles were discovered. The screening procedures for the entire text, headline, and abstract eliminated duplicate and non-value-added Technical Debt (TD) studies (see Figure 1). Page et al. (2021) confirmed the inclusion of the PRISMA framework and proposed a method for presenting critical appraisal evidence.

Figure 3 PRISMA diagram illustrating the article selection process Forward and backward snowballing were applied to the 28 articles identified by the PRISMA screening procedure using the parameters outlined by Li et al (2015). An iteration of the snowballing procedure was performed to help ensure the applicability of the retrieved studies. Although no new publications were created as a result of the procedure, one study that was less relevant to Technical Debt (TD) in a Saudi context was dropped. 3.3 Data Extraction and Synthesis Before assigning a score, each investigator who participated in the data extraction procedure read the entire text of each article. The grade indicated how effectively the research addressed the major topics and research questions. After reading the publications, the researchers met to discuss the findings. Articles with higher ratings take precedence. The findings were combined using descriptive quantitative data analysis and thematic analysis of data on Technical Debt (TD) in Saudi Arabia and elsewhere. Thematic analysis is a well-known data analysis technique (Kiger & Varpio, 2020; Vaismoradi et al., 2013). Content analysis, in conjunction with inductive and deductive reasoning, established the basic patterns in monitoring and controlling technical debt in new and legacy software systems. Each theme was assigned a research question. The only issue with theme analysis was the inability to infer causal relationships. Unstandardized theme analysis was also called into question by Nowell, Norris, White, and Moules (2017). 5. Results and Discussion 4.1 The contribution of Cultural practices in Software Engineering on Technical Debt The context of technology adoption in Saudi Arabia demonstrates the impact of culture on software engineering methods. Previously, Information Communications Technology (ICT) use was restricted to government agencies and businesses in high-priority industries such as oil and gas (including Aramco) (Almowanes, 2017). Slow adoption of computing technologies in Saudi Arabia could be attributed to societal acceptance, historical, financial, and cultural factors, as well as the government's concerns about technology and its alleged effects on communications, religion, and national security (Almowanes, 2017; Alshahrani, 2016). The unified theory of acceptance and use of technology (UTAUT), which proposed that user intentions could predict the acceptability of new technologies, behaviors, effort, and performance expectancy (Alshareef & Tunio, 2022), offered an alternative explanation for Information Communications Technology (ICT) adoption disparities (see Figure 2). Given that the model correctly predicted the barriers and facilitators of blockchain system adoption in KSA technology SMEs, it can help predict the risk of Technical Debt (TD) accumulation.

Figure 4 UTAUT theory in the context of software Technical Debt (TD) in KSA Beyond UTAUT, KSA's high levels of collectivism and uncertainty avoidance are cultural impediments to technological advancement (Almowanes, 2017). Almowanes' (2017) concerns about the influence of regional cultures on the adoption of Information Communications Technology (ICT) systems in KSA were consistent with Hofstede's (2022) model. Figure 3 compares uncertainty avoidance in the Kingdom of Saudi Arabia to that in the United States, the United Kingdom, and China. According to the graph, KSA had the lowest levels of indulgence and the highest levels of uncertainty avoidance (Hofstede, 2022). Figure 5 Uncertainty avoidance in the KSA versus other countries of interest The current body of research on the relationship between cultural traits and software engineering practices lends support to the use of Hofstede's model to forecast software practices and the potential danger of Technical Debt (TD) accumulation (Darwish & Henryson, 2019). The study of technology serves as a catalyst for national development and long-term thinking (Cetinguc et al., 2020). A cross-national study involving Sweden, Indonesia, Japan, and China discovered that higher levels of long-term orientation were associated with specific behaviors among software professionals (Darwish & Henryson, 2019). Depending on your point of view, the national cultural patterns of the software industry may help or hinder control of planned and unplanned Technical Debt (TD). Long-term orientation was characterized by high levels of bug monitoring, restructuring, progress measurement, and regular risk assessment of software systems (Darwish & Henryson, 2019). To reduce uncertainty in the countries of interest, the software developers prioritized early design choices, test-first programming, and upfront requirement specification (Darwish & Henryson, 2019). Each of the three conditions could reduce the accumulation of Technical Debt (TD), especially given that workarounds were partially to blame for unplanned Technical Debt (TD) (Griffith et al., 2015; Klinger et al., 2011; Salaou et al., 2021). The findings of Hofstede's model may enable proactive Technical Debt (TD) monitoring in Saudi software firms. However, there aren't enough facts to back up these theories in the Saudi software ecosystem. 4.2 Comparison of TD Frameworks and Criteria in KSA, US, UAE, Germany, New Zealand, Brazil, and Finland Because of the lack of current data, the comparison of TD frameworks and features between KSA and other nations concentrated on a small number of countries. US's IBM method for managing debt included the following steps: determining the types of debt that are due, preventing the buildup of additional debt, choosing the most practical debt reduction strategy, and carrying out the plan (Brown, 2022). The TD review procedure need to be guided by the basic inquiries listed below: Is TD current? What parts are the most challenging to change? What TD features are crucial for the company? The problems outlined in IBM's TD management framework just served as a microcosm of the norms followed by US technology businesses in general (Pérez et al., 2021). The structure and standards for assessing TD that Brown (2022) emphasized were similar to those used in the KSA. Organizations in the KSA that rely on antiquated technology were looking on ways to lessen TD buildup. An illustration of this was Umm Al-Qura University (Alkazemi et al., 2012; Alkazemi et al., 2013). Additionally, KSA-based technology firms like Intellias and Wakeb were spending money on AI and ML tools for software development (Intellias Saudi, 2022; Wakeb, 2022). The application of intelligent systems was less prone to TD buildup. According to Intellias, Umm Al-Qura University, and Wakeb software practices, it seems to be appropriate to say that KSA's framework for TD management was dual-faceted, with investments in AI and the progressive phasing out of outdated systems occurring at the same time. In contrary to Brazil, Finland, and New Zealand, where controlling TD maintained difficult due to information asymmetry, the KSA and the US had criteria and procedures for doing so (see Figure 6). (Holvitie et al., 2018). A poll of business professionals in the three nations found that there were no reliable systems in place to stop TD from building up. For instance, the practitioners acknowledged that the software assessment criteria, tests, and documentation were all poor (Holvitie et al., 2018). The results showed that breaking coding best practices was widespread.

Figure 6:Causes of TD in Brazil, Finland, and New Zealand (Holvitie et al., 2018) Agile systems were essential to risk management in the software development sector in the UAE, in contrary to the subpar frameworks and criteria Holvitie et al. (2018) identified in Brazil, Finland, and New Zealand (Hawanreh, 2022). The conclusions reached by Holvitie et al. (2018) were comparable to those of Pérez et al. (2021) research conducted in Brazil, Chile, Colombia, and the US, where technology companies had tried to suppress TD accumulation by implementing best practices, better design, and refactoring amongst many other strategies shown in Figure 2. The strict standards used for TD management in Brazil, Chile, Colombia, and the US might be replicated to satisfy the local standards in KSA.

Figure 7: TD causes and management practices in Brazil, Chile, Colombia, and the United States (Pérez et al., 2021) Trying to follow the evaluation of the TD frameworks and requirements in Brazil, Finland, New Zealand, the United Arab Emirates, Chile, Colombia, and the United States, Holvitie et al. (2018), Hawanreh (2022), and Pérez et al. (2021) demonstrate that the best management and monitoring techniques for software technical debt were country specific. The future of TD management was severely hampered by the lack of defined measurements. 4.3 Legacy Systems and TD Barriers to switching from legacy software systems at Umm Al-Qura University serve as the finest example of how old systems affect TD in the KSA software ecosystem. The legacy problems found at Umm Al-Qura University were, but a microcosm of the larger problems Saudi software engineers have to deal with in order to reduce the buildup of unintended TD in public and private entities (Alkazemi et al., 2012; Alkazemi et al., 2013). The findings of Evans et al. (2019) and Alkazemi et al. (2012) support the study by Ibarra & Gabriel (2012) of the special advantages and difficulties connected with legacy system government institutions in KSA, the US, and elsewhere. It has been difficult to start the transition from legacy systems to next-generation software platforms since the conventional IT platforms served different purposes and had a long track record of success. In the US Department of Defense and NASA, for instance (Evans et al., 2019; Ibarra & Gabriel, 2012), this meant that the danger of unexpected TD buildup would persist as long as legacy software systems were in use. Positively, the KSA had less risk of accruing TD from legacy systems given that the majority of the ICT infrastructure was relatively new compared to the West, with the exception of the banking software created using COBOL code (Almowanes, 2017; Alshahrani, 2016). (Protiviti, 2022; Monaghan & Bass, 2020). The ICT sector in the KSA did not begin to develop until the early 1990s and late 1980s (Almowanes, 2017), and public internet access only started in 1999. (Alshahrani, 2016). Given that demand and software development are interwoven, internet penetration levels have a cascading influence on both (Hakiri et al., 2015; Saleem et al., 2019). Nevertheless, data from the banking system and the Umm Al-Qura University case study revealed that early adopters of software systems—primarily government institutions—were at risk of acquiring excessive amounts of TD. Not only KSA continues to rely on antiquated software platforms. The problem is widespread throughout the world. According to a Protiviti (2022) survey, and over 90% of the world's top 100 banks and almost two-thirds of the Fortune 500 rely on legacy software systems to support their core software processes. The legacy systems tend to support $3 trillion in daily transactions, which almost all ATM transactions worldwide, including those in KSA, fall within (Protiviti, 2022). There is no reason to update the roughly 220 billion lines of code created in the 1950s and 1960s - more than six decades ago - as COBOL and other legacy technologies have been shown to remain durable over time (Protiviti, 2022). He also expressed worries regarding a possible connection between both the COBOL code and TD, which were in line with Monaghan & Bass's (2020) observation that COBOL and Fortran were highly desired due to their dependability in handling significant financial transactions.

5. Conclusion The research study added fresh knowledge that is pertinent to software developers in KSA and expanded our present understanding of the sources of TD in the software development lifecycle. Given that the GCC and other nations with Islamic banking systems share similar technical, economical, and cultural settings, the results have wider significance for them (Algaeed, 2022; Alshater et al., 2022). The successful completion of KSA's big ideas under Vision 2030 and the national reform plan, including the installation of 5G hyper-connectivity, investment opportunities in AI and robotics, intelligent analytics and scalable systems, AR and VR, and smart cities like NEOM, depended on the proper management of planned and unplanned TD. Future software policies and practices would be shaped by the fresh ideas and insights. Despite the paucity of data on TD in KSA, trends were deduced from software development methods and tech firms as Intellias Saudi, Wakeb, and Sakhr. A sign of an impending risk of TD buildup, for instance, was the continuous usage of old software systems at Almabani General Construction Company and Umm Al-Qura University. The buildup of TD was accelerated by the lack of technical expertise along with other external restrictions. The lack of scholarly study on TD in KSA made it difficult to draw conclusions about how Saudi Arabian technology firms manage legacy systems and the buildup of software technical debt. Private businesses and governmental organizations may be susceptible to legacy system-based TD, according to the Almabani General Construction Company and Umm Al-Qura University old software system case. KSA was not the only country that struggled to move away from antiquated systems. In the US, a related event was seen. The cost of switching to modular, service-driven software as well as the longevity of the legacy software's reliability were some of the reasons that influenced the decision to preserve old systems. From another angle, sociocultural uncertainty avoidance may be the cause of the resistance to embracing new technology. The fusion of cultural norms, customs around software development, and economic factors foresaw TD in KSA. The advent of new technologies has posed a challenge in balancing the trade-off between prices, performance, source code flexibility, and cultural dynamics in host communities. Cultural dynamics, such as masculinity, uncertainty avoidance, individualism, collectivism, indulgence, and long-term orientation, play a crucial role in shaping the impact of Technical Debt (TD) in organizations. In Saudi Arabia, the high level of uncertainty avoidance may result in a slow adoption of intelligent Technical Debt (TD) management methods. However, the benefits of artificial intelligence and machine learning are expected to outweigh the difficulties faced during the initial stages of implementation. Technical debt can arise both intentionally and unintentionally through violations of coding best practices, poor software design, and quick and simple solutions intended to release products to the market or save time and resources. These practices may result in shifting Technical Debt (TD) costs to other stakeholders or repeating them in the future. The interconnected nature of the MENA economies and industries means that the Technical Debt (TD) practices in KSA are relevant and could positively or negatively impact the expansion of the Information Communications Technology (ICT) industry in the region.

References Ahmad, A., Alkhalil, A., Altamimi, A. B., Sultan, K., & Khan, W. (2021). Modernizing Legacy Software as Context - Sensitive and Portable Mobile-Enabled Application. IT Professional, 23(1), 42–50. https://doi.org/10.1109/MITP.2020.2975997. Aldaeej, A., & Seaman, C. (2022). The Negative Implications of Technical Debt on Software Startups: What they are and when they surface. Proceedings - 5th International Workshop on Software-Intensive Business: Towards Sustainable Software Business, IWSiB 2022, 23–30. https://doi.org/10.1145/3524614.3528629. Alfayez, R., Alwehaibi, W., Winn, R., Venson, E., & Boehm, B. (2020). A systematic literature review of technical debt prioritization. Proceedings - 2020 IEEE/ACM International Conference on Technical Debt, TechDebt 2020, 1–10. https://doi.org/10.1145/3387906.3388630 Algaeed, A. H. (2022). Government Spending Volatility and Real Economic Growth: Evidence From a Major Oil Producing Country, Saudi Arabia, 1970 to 2018. SAGE Open, 12(2), 1–13. https://doi.org/10.1177/21582440221089948 Almowanes, A. (2017). History of Computing in Saudi Arabia- A Cultural Perspective. International Journal of Social Science and Humanity, 7(7). https://doi.org/10.18178/ijssh.2017.7.7.862 Alshahrani, H. A. (2016). A Brief History of the Internet in Saudi Arabia. TechTrends, 60(1), 19–20. https://doi.org/10.1007/s11528-015-0012-5 Alshater, M. M., Saba, I., Supriani, I., & Rabbani, M. R. (2022). Fintech in islamic finance literature: A review. Heliyon, 8(9), e10385. https://doi.org/10.1016/j.heliyon.2022.e10385. Alshareef, N., & Tunio, M. N. (2022). Role of Leadership in Adoption of Blockchain Technology in Small and Medium Enterprises in Saudi Arabia. Frontiers in Psychology, 13, 1–11. https://doi.org/10.3389/fpsyg.2022.911432 Alves, N; Mendes, T; Mendonça, M; Spínola, R; Shull, F; Seaman, C. (2016). Identification and Management of Technical Debt: A Systematic Mapping Study. Information and Software Technology, 70, 100 – 121. Ampatzoglou, A., Ampatzoglou, A., Avgeriou, P., Chatzigeorgiou, A., 2016. A financial approach for managing interest in technical debt. Lecture Notes Bus. Inf. Process. 257, 117–133. Besker, T., Martini, A., Bosch, J., 2018. Managing architectural technical debt: a unified model and systematic literature review. J. Syst. Softw. 135, 1–16 Supplement C. Beck, K; Beedle, M; Van Bennekum, A; Cockburn, A; Cunningham, W; Fowler, M; Grenning; Highsmith, J; Hunt, A; Jeffries, R et al. (2001). Manifesto for agile software development. Online, URL: http://agilemanifesto.org/. Beck, K; Andres, C. (2004). Extreme Programming Explained: Embrace Change, Addison-Wesley Professional. Bitbucket. (2022). What is version control? https://www.atlassian.com/git/tutorials/what-is-version-control. Bogner, J., Verdecchia, R., & Gerostathopoulos, I. (2021). Characterizing Technical Debt and Antipatterns in AI-Based Systems: A Systematic Mapping Study. Proceedings - 2021 IEEE/ACM International Conference on Technical Debt, 64–73. https://doi.org/10.1109/TechDebt52882.2021.00016 Brings, J., Salmon, A., & Saritas, S. (2015). Context uncertainty in requirements engineering: Definition of a search strategy for a systematic review and preliminary results. CEUR Workshop Proceedings, 1342, 171–178. Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P., Lim, E., MacCormack, A., Nord, R., Ozkaya, I., Sangwan, R., Seaman, C., Sullivan, K., & Zazworka, N. (2010). Managing technical debt in software-reliant systems. Proceedings of the FSE/SDP Workshop on the Future of Software Engineering Research, FoSER 2010, 47–51. https://doi.org/10.1145/1882362.1882373. Cetinguc, B., Calik, E., & Calisir, F. (2020). The Moderating Effect of Long-Term Orientation on the Relationship Among Human Capital Research, Business Sophistication, and Knowledge & Technology Outputs. In Industrial Engineering in the Digital Disruption Era (pp. 291–296). Springer Berlin Heidelberg. CodeScene. (2022). Business costs of technical debt. 1–15. Darwish, A., & Henryson, A. (2019). How do Cultural Characteristics and Software Engineering Practices Interplay? A Comparative Study Between Indonesia and Sweden. University of Gothenburg and Chalmers University of Technology, 1–15.

 Dingsøyr, T; Nerur, S;  Balijepally, V; Moe, N. (2012). A decade of agile methodologies: towards explaining agile software development, J. Syst. Softw. 85  (6), 1213–1221.

Evans, S., Taber, W., Drain, T., Smith, J., Wu, H., Guevara, M., Sunseri, R., & Evans, J. (2019). MONTE: The Next Generation of Mission Design and Navigation Software. Jet Propulsion Laboratory—California Institute of Technology, 1–8. Gijsen, N. (2020). Balancing software maintenance effort as a technical debt management strategy. University of Twente. Griffith, I., Taffahi, H., Izurieta, C., & Claudio, D. (2015). A simulation study of practical methods for technical debt management in agile software development. Proceedings - Winter Simulation Conference, 1014–1025. https://doi.org/10.1109/WSC.2014.7019961. Hawanreh, N. H. (2022). Risk Management in Agile Software Development in UAE Governmental Sector. The British University in Dubai. Hofstede, G. (2022). Hofstede’s Insights: Saudi Arabia. https://www.hofstede-insights.com/country-comparison/china,saudi-arabia,the-uk,the-usa/. Holvitie, J., Licorish, S. A., Spínola, R. O., Hyrynsalmi, S., MacDonell, S. G., Mendes, T. S., Buchan, J., & Leppänen, V. (2018). Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology, 96, 141–160. https://doi.org/10.1016/j.infsof.2017.11.015. Ibarra, A., & Gabriel, C. (2012). Solving the Software Legacy Problem with RISA. Astronomical Society of the Pacific Conference Series, 461, 643–646. Intellias Saudi. (2022). Digital product engineering services. https://intellias.com/intellias-saudi/ Invest Saudi. (2020). IT Services and Software: Investment Opportunity Scorecard. 1–5. Kiger, M. E., & Varpio, L. (2020). Thematic analysis of qualitative data : AMEE Guide. Medical Teacher, 0(0), 1–9. https://doi.org/10.1080/0142159X.2020.1755030 Keshta, I., Niazi, M., & Alshayeb, M. (2017). Towards Implementation of Requirements Management Specific Practices (SP1.3 and SP1.4) for Saudi Arabian Small and Medium Sized Software Development Organizations. IEEE Access, 5, 24162–24183. https://doi.org/10.1109/ACCESS.2017.2764490. Lenarduzzi, V., Besker, T., Taibi, D., Martini, A., & Arcelli Fontana, F. (2021). A systematic literature review on Technical Debt prioritization: Strategies, processes, factors, and tools. Journal of Systems and Software, 171, 110827. https://doi.org/10.1016/j.jss.2020.110827 Li, Z., Avgeriou, P., Liang, P., 2015. A systematic mapping study on technical debt and its management. J. Syst. Softw. 101, 193–220. McConnell, S. (2007). Technical debt. Online, URL: http://www.construx.com/10x_ Software_Development/Technical_Debt/. Monaghan, B. D., & Bass, J. M. (2020). Redefining Legacy: A Technical Debt Perspective BT - Product-Focused Software Process Improvement. In M. Morisio, M. Torchiano, & A. Jedlitschka (Eds.), International Conference on Product-Focused Software Process Improvement (pp. 254–269). Springer International Publishing. Mumtaz, M., Ahmad, N., Usman Ashraf, M., Alghamdi, A. M., Bahaddad, A. A., & Almarhabi, K. A. (2022). Iteration Causes, Impact, and Timing in Software Development Lifecycle: An SLR. IEEE Access, 10, 65355–65375. https://doi.org/10.1109/ACCESS.2022.3182703 Nowell, L., Norris, J., White, D., & Moules, N. (2017). Thematic Analysis: Striving to Meet the Trustworthiness Criteria. International Journal of Qualitative Methods, 16(1), 1–13. https://doi.org/10.1080/17439760.2016.1262613 Page, M. J., McKenzie, J. E., Bossuyt, P. M., Boutron, I., Hoffmann, T. C., & Mulrow, C. D. (2021). The PRISMA 2020 statement: an updated guideline for reporting systematic reviews. BMJ, 372, 71. Protiviti. (2022). Is Technical Debt Limiting Your Company’s Competitiveness? https://www.protiviti.com/OM-en/insights/bpro109. Randhawa, T. S. (2022). Software Life Cycle BT - Mobile Applications: Design, Development and Optimization. In T. S. Randhawa (Ed.), Mobile Applications (pp. 1–55). Springer International Publishing. https://doi.org/10.1007/978-3-030-02391-1_1. Schein, E. (2016). San Francisco: Jossey-Bass. Schwaber, K; Beedle, M. (2002). Agile software development with Scrum, 18 Prentice Hall PTR Upper Saddle River, NJ. Stol, K. J., & Fitzgerald, B. (2018). The ABC of software engineering research. ACM Transactions on Software Engineering and Methodology, 27(3), 11–51. https://doi.org/10.1145/3241743. Veryant. (2022). Almabani General Contractors: Accounting, finance, invoicing, and asset management software. 1–4. Wakeb. (2022). Custom Software Development. https://wakeb.tech/solutions/software-development. Ward Cunningham. 1992. The WyCash portfolio management system. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA, Vol. Part F1296. 29–30. https://doi.org/10.1145/157710. 157715. Watts, S., & Kidd, C. (2018). Refactoring Resolves Technical Debt. BMC. https://www.bmc.com/blogs/code-refactoring-explained/. Xuan, J., Hu, Y., & Jiang, H. (2012). Debt-Prone Bugs: Technical Debt in Software Maintenance. International Journal of Advancements in Computing Technology, 4(19), 453–461. Zhou, Y., Xia, Q., Zhang, Z., Quan, M., & Li, H. (2022). Artificial intelligence and machine learning for the green development of agriculture in the emerging manufacturing industry in the IoT platform. Acta Agriculturae Scandinavica Section B: Soil and Plant Science, 72(1), 284–299. https://doi.org/10.1080/09064710.2021.2008482 Eng. Anna (talk) 14:31, 13 February 2023 (UTC)