No One Left Behind: Cross-Level Analysis for Sustainable Software Engineering

arXiv:2609.03861v1 [cs.SE] 3 Sep 2026

No One Left Behind: Cross-Level Analysis for Sustainable Software Engineering Masoum Salehi

Sandro Schulze

Jacob Krüger

Anhalt University of Applied Sciences Köthen, Germany masoum.salehi@hs-anhalt.de

Anhalt University of Applied Sciences Köthen, Germany sandro.schulze@hs-anhalt.de

Eindhoven University of Technology Eindhoven, The Netherlands j.kruger@tue.nl

Abstract—Software engineers expect a software system to be efficient, maintainable, economically viable, and socially responsible throughout its lifecycle. Unfortunately, decisions made at the organizational, process, or product levels of software development—even when they improve one of these goals— often have unintended long-term consequences at other levels. In response, software-engineering research has explored different ways to achieve software sustainability, including energy efficiency, resource optimization, and code maintainability. However, existing research offers limited explanations for how sustainability problems emerge and reinforce one another across the socio-technical levels of software engineering. Moreover, we argue that sustainability challenges are not isolated but rather systemic: They stem from interactions among organizational priorities, development practices, and technical conditions. In this vision paper, we introduce the concept of sustainability antipatterns to capture conditions that systematically produce unsustainable outcomes. We demonstrate how this concept can help expose cross-level misalignments between socio-technical levels and sustainability dimensions that remain difficult to recognize through artifact-centric or dimension-specific analyses. To guide future research, we outline concrete directions for identifying, formalizing, detecting, and mitigating sustainability anti-patterns. We envision sustainability anti-patterns as a foundation for an integrated and actionable research agenda on sustainable software engineering. Index Terms—Software Sustainability, Sustainable Software Engineering, Sustainability Anti-Patterns

I. I NTRODUCTION Software is crucial for almost all aspects of modern society. As such, the long-term sustainability of software is essential. Software sustainability is understood as a systematic and multidimensional concept that goes beyond energy optimization: It also captures the technical durability, social equity, and economic viability of the software lifecycle [3]. Yet, as recent studies argue [11], [13], [27], sustainability research in software engineering is in its infancy. Critically, a multidimensional view is largely missing in empirical softwareengineering research [6], [16]. So far, research has evolved largely in parallel by considering dimensions with their inherent goals in isolation. For example, energy-efficiency research [12], [17] aims to reduce the energy consumption and carbon footprint of software systems; technical sustainability research [1], [27] emphasizes software quality; and research on developer wellbeing [21], [26] examines human and organizational factors for

sustainable practices. Research on each of these dimensions provides valuable insights, but is often done within distinct research communities that have own assumptions, metrics, and methodologies. As a result, existing research provides limited support for understanding how sustainability problems emerge, interact, and reinforce each other over time. We argue that this limitation stems from a deeper mismatch between how sustainability has been studied and how software systems are developed. Software development is a sociotechnical activity, meaning that it consists of organizational (social structures), process (work practices), and product (artifacts) levels [2]. These levels are interconnected: choices made at one level influence outcomes at others [26]. For instance, organizational decisions to prioritize system delivery may lead to reduced testing as a process-level shortcut. In turn, complexity may increase, energy consumption can rise, and developers may become frustrated with the codebase. The question we want to pose for future research is: How can we understand and solve problems that span across socio-technical levels and affect multiple sustainability dimensions? This question gains critical urgency with the rise of AI-assisted and agentic development, where fast-paced automation outpaces human oversight and lets sustainability problems emerge and compound unnoticed. As a step in this direction, we introduce sustainability antipatterns as a new concept for analyzing sustainable software engineering. A sustainability anti-pattern is a recurring pattern of interconnected socio-technical problems that collectively result in unsustainable outcomes. By capturing interconnections across both, socio-technical levels and sustainability dimensions, we provide a lens through which systemic sustainability problems can be made visible and actionable. In this vision paper, we define the concept of sustainability antipatterns, distinguish it from related concepts like traditional anti-patterns, illustrate its use through an example, and outline a research agenda for cataloging, detecting, measuring the impact on sustainability, and mitigating sustainability antipatterns in software development. II. T HE N EED FOR S USTAINABILITY A NTI - PATTERNS Software-engineering research has made significant contributions to software sustainability since this topic gained popularity in 2010 [19]. However, current research is fragmented

© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

Sustainability Dimensions ECONOMIC

SOCIAL

TECHNICAL

ENVIRONMENTAL

INDIVIDUAL

Wasted Energy

Developer Burnout

ORGANIZATION

TOP-DOWN PRESSURE (Policies & Decisions)

BOTTOM-UP IMPACT (Results & Complexity)

Socio-technical Levels

Policy Conflict (Short-term Profit)

PROCESS Process Shortcut

PRODUCT

Technical Debt

Fig. 1. Exemplary overview of our socio-technical sustainability lens, illustrating how sustainability anti-patterns capture interactions across organizational, process, and product levels as well as across sustainability dimensions.

and does not fully capture the interconnected and recurring nature of sustainability problems. In this section, we discuss two major limitations that motivate our vision. A. Patterns and Anti-patterns Patterns are reusable, proven solutions to recurring problems within a given context. This concept was introduced in 1994 by Gamma et al. [10], who documented recurring design solutions to common problems in object-oriented systems. In contrast, anti-patterns describe commonly repeated solutions that appear beneficial but ultimately produce negative consequences [5]. Anti-patterns often look like good ideas initially (a solution) but lead to bad outcomes (negative consequences). Several researchers cataloged patterns and anti-patterns across software development. For example, at the product level, code smells [9] indicate surface-level indicators of deeper design problems, such as duplicated code or long methods. At the process level, Brada and Picha [4] have identified process anti-patterns, which undermine project management effectiveness. At the organizational level, community smells [25] describe dysfunctional social structures—such as organizational silo or lone wolf—that hinder collaboration and knowledge sharing. However, these traditional patterns are typically studied in isolation and are rarely analyzed from a sustainability perspective. Even though recent research has introduced sustainability smells [14], energy smells [20], and sustainability design patterns [15], these efforts focus on linking code and energy consumption. They still treat the problem as a technical optimization task. However, software systems’ non-sustainability is systemic: multiple problems can co-occur and amplify one another. Subsequently, addressing a problem in isolation may fail if the underlying systemic configuration remains

stable. The widespread reliance on technical debt [7] illustrates this limitation clearly. Technical debt captures the accumulated cost of implementation shortcuts at the product level, representing an isolated artifact-centric symptom. However, it fails to account for the organizational conditions driving those shortcuts (cf. Figure 1), the process-level practices that allow debt to grow unchecked, or downstream sustainability consequences (e.g., developer burnout or wasted energy) that accumulate as a result. Addressing technical debt in isolation, without changing the cross-level socio-technical conditions that produced it, is precisely the kind of incomplete intervention that motivates our work. B. Systemic Nature of Sustainability Systems thinking is a comprehensive approach that focuses on how different components of a system interact and influence each other throughout time [23]. Software sustainability problems are, by their nature, complex system problems [22]. In most cases of systemic interest, a sustainability problem cannot be fully explained by a single line of code, a single development practice, or a single organizational policy in isolation. Rather, it emerges from—or is significantly amplified by—the interplay of decisions across socio-technical levels and shows direct or indirect impact on one or more sustainability dimensions. Current research treats a chosen dimension and level as the primary area of analysis and rarely bridges the gap between organizational structures, development processes, and technical artifacts. Without such a holistic view, it remains unclear how local decisions propagate through the socio-technical levels of a project or how they reinforce each other across sustainability dimensions. The Karlskrona Manifesto [3] as a foundation for sustainability design frames sustainability as such a systemic multi-dimensional concern.

Other researchers have also acknowledged the systemic nature of sustainability [16], [18]. Unfortunately, empirical software-engineering research remains largely dominated by a reductionist paradigm, where the focus is on optimizing isolated system components, such as energy consumption or code maintainability. While this modularity is a cornerstone of traditional engineering, it is insufficient for sustainability, which is an emergent property of an entire socio-technical system. Some researchers have proposed systems thinking to improve sustainability in software engineering. Among others, finding leverage points as intervention targets for sustainability [22], requirements engineering as a systemic bridge [8], or a capability maturity framework [24] to assess an organization’s software sustainability have been proposed. However, these efforts have remained largely theoretical and treat sustainability as static levels rather than dynamic behavior. Consequently, the software-engineering community still lacks a practical concept for identifying, cataloging, analyzing, and mitigating systemic sustainability problems in real-world projects. III. T HE VISION : S USTAINABILITY A NTI - PATTERNS The limited systemic view of sustainable software engineering we discussed in Section II motivates the need for a concept to systematically capture cross-level socio-technical relationships and sustainability dimensions. In Figure 1, we sketch an overview of our vision for moving towards such a systemic view based; including the example of technical debt. We introduce sustainability anti-patterns as a new concept for capturing recurring cross-level patterns, which collectively lead to unsustainable outcomes. Building on the notion of antipatterns in software engineering [5], we define a sustainability anti-pattern as follows: Definition: Sustainability Anti-pattern A sustainability anti-pattern is a recurring socio-technical pattern in which interacting organizational priorities, development practices, and technical decisions intend to create short-term local benefits while systematically generating long-term unsustainable outcomes that span across sustainability dimensions. Our definition of sustainability anti-patterns extends traditional anti-pattern definitions [5] in three important ways. First, it focuses on multi-level socio-technical patterns rather than isolated artifacts. Second, consequences are acknowledged to spread across sustainability dimensions. Lastly, it highlights how seemingly rational short-term decisions can lead to longterm systemic failure. In our idea, such anti-patterns emerge from how choices, actions, and systems at different sociotechnical levels connect to and influence one another. Specifically, this involves: (1) the organizational level (e.g., strategic priorities, incentive structures), (2) the process level (e.g., development practices, coordination mechanisms), and (3) the product level (e.g., code quality issues, technical debt).

ORGANIZATIONAL LEVEL

PROCESS LEVEL

PRODUCT LEVEL

Decisions & Priorities

How Work Gets Done

What Gets Built

Delivery Pressure Short-term focus

Rushed Process Insufficient quality practices

Skipped Refactoring Shortcuts accumulate

Lost revenue Developers quitting Customers complain

Feedback loop Consequences increase future pressure unless the system is changed

Technical Debt Complexity, Fragility

High Energy Use Wasted compute

Developer Burnout Stress, Fatigue

Fig. 2. An example of how sustainability problems propagate across sociotechnical levels and amplify.

It is worth to note that our definition also captures how we intend to identify and address sustainability problems holistically. We envision to shift the focus towards the emergence of system-level effects from local decisions, rather than evaluating artifacts or practices in isolation. This encourages researchers and practitioners to move beyond localized metrics towards examining interrelated patterns and their evolution over time. However, to operationalize such patterns, it requires reasoning about complex dependencies rather than simple observations (cf. Section IV). In the following, we illustrate the practical relevance of our vision through an example. In Figure 2, we illustrate a high-level example of a sustainability anti-pattern. Note that this is not intended as an empirical finding, but as a conceptual instantiation that shows how local decisions across socio-technical levels may create unsustainable outcomes. Imagine a situation in software development where the organization’s success is frequently measured in terms of short-term delivery metrics (e.g., feature throughput or release frequency). While this priority is often justified by market demands or competition, it can lead to decisions and practices at the process level that prioritize speed over rigor. For example, to meet tight deadlines, the development team may decide to reduce testing effort, skip refactoring, or minimize architectural discussions. This leads to technical debt at the product level [1]—consciously or unconsciously, often with the expectation that it can be fixed later. Over time, the system becomes complex, making it more difficult to modify, evolve, and even understand. Subsequently, developers must invest more time and effort to implement changes, fix bugs, and ensure system stability. In some cases, inefficient implementations due to time constraints may also lead to higher resource consumption or poor performance [20]. Eventually, developers may face burnout and turnover [26] while users experience declining product performance. Even worse, such effects do not remain local but propagate across levels and (sustainability) dimensions. In response, organizations may reinforce the original priorities, which results in a circle in which short-term optimizations continuously generate long-term costs. The example illustrates what a sustainability anti-pattern looks like and what it captures. Sustainability failures are not

isolated technical issues, but rather cross-level misalignments between organizational priorities, development processes, and technical conditions. This structure produces unsustainable outcomes across multiple dimensions: technical (poor quality), environmental (energy waste), economic (increased maintenance cost), and human (developer burnout). While such individual outcomes have been researched in isolation, holistic anti-patterns, as in our example, have not been made explicit, yet. We hypothesize that variants of such anti-patterns are common across software projects. However, in practice, they may vary in their specific causal paths, degrees of impact, and contextual triggers. We envision to identify, document, validate, and mitigate such patterns so that practitioners can recognize them and researchers can study them cumulatively. IV. R ESEARCH ROADMAP To adopt sustainability anti-patterns as a lens for understanding software sustainability, we see several research opportunities and challenges. In the following, we outline key directions that together define an actionable agenda. Understanding Sustainability Anti-Patterns. The first step is to know how patterns of unsustainability actually look like in practice. In our vision, sustainability problems arise across socio-technical contexts and sustainability dimensions. This is grounded in systems thinking [28] and consistent with the socio-technical nature of software development [2], but the evidence is scattered across silos. We envision a systematic synthesis of existing literature to document currently separated sustainability concerns. Understanding how these connect and reinforce each other remains an open problem. Systems-thinking methods, such as causal loop diagrams and the iceberg model, can enable researchers to hypothesize antipatterns from findings that have already been published but never connected. Also, we call for direct field investigations. Empirical studies are essential, including practitioner interviews or software repository mining of process artifacts (e.g., issue trackers, CI logs) and organizational signals (e.g., team structures, workload distribution). Moreover, it is important to understand how the growing adoption of AI-assisted development and agentic systems creates new socio-technical dynamics that must be taken into account as well. We call for future work to investigate whether existing anti-pattern categories require extension or entirely new categories to account for these dynamics. Formalization. Since different researchers may describe the same anti-pattern differently, a shared, structured language for representing sustainability anti-patterns is important. Towards this direction, we need a formal template that specifies the essential elements of every anti-pattern. Such a template can be drawn from software design-patterns, but must capture socio-technical contexts and sustainability dimensions that design patterns are not intended to represent. We envision a structured template that captures, at least, an anti-pattern’s name, socio-technical context, observable symptoms, impacted sustainability dimensions, and potential mitigation strategies. Equally critical is to define what a sustainability anti-pattern

is not. We suggest that a sustainability anti-pattern must satisfy two conditions: (1) recurrence across multiple projects and contexts and (2) an observable impact on more than one sustainability dimension. The first condition distinguishes sustainability anti-patterns from one-off project failures, while the second condition distinguishes them from dimensionspecific problems, such as isolated technical debt. However, operationalizing both conditions remains a research challenge in itself, and the thresholds we propose are starting points subject to empirical refinements. When issues are strictly onedimensional (e.g., a localized dip in technical performance without evidence of cross-dimensional propagation), existing concepts like technical debt or energy smells remain more appropriate framings. Detection and Tooling. To bridge the gap between research and practice, we need to make sustainability anti-patterns actionable for practitioners. This requires tool support. However, a sustainability anti-pattern may manifest as measurable signals across different layers of socio-technical systems. Some indicators may reside in software repositories (e.g., code complexity trends, energy consumption profiles, test coverage decline, or coordination patterns). Other indicators exist only in practitioners’ knowledge (e.g., organizational pressure, implicit team norms, or the real thoroughness of code). Yet, no single method currently examines them together. So, to capture a full anti-pattern, we propose combining repository mining with practitioner inquiries. For example, a structured self-assessment checklist could reference both repository metrics and human judgment, helping a team to check whether a known anti-pattern matches their project. Future tools must support continuous monitoring and analysis of sustainability anti-patterns. For example, dashboards and DevOps pipeline integrations could flag threshold violations before the underlying issues become systemic failures. Intervention. After detecting a sustainability anti-pattern, the ultimate goal is to fix it. In our idea, sustainability antipatterns represent recurring patterns of interacting problems. Thus, to address them, we require more than just local fixes (e.g., code refactoring). This means that we need effective interventions that may require changes at multiple levels at the same time. For example, to mitigate an anti-pattern that is caused by delivery pressure, we may need to align incentives, adjust development practices, and restructure parts of the system architecture. Future research must therefore develop and evaluate such mitigation strategies that match the sociotechnical nature of each anti-pattern and understand potential trade-offs across sustainability dimensions. However, evaluating such strategies in real organizations is difficult, since some interventions are too risky to attempt, and sustainability outcomes may unfold only after months or years. Methods like longitudinal studies, quasi-experimental field studies, and simulation models may help researchers as a complementary way to explore intervention dynamics that are too slow or risky to study in real organizations. Sustainability Impact. To know whether a remediation works, we must measure the impact anti-patterns have. However,

this measurement is challenging because sustainability impacts accumulate across multiple sustainability dimensions on different timescales. For example, energy costs may increase over months, developer burnout may take years to manifest, and erosion of community trust leaves no digital trace. In addition, understanding how to separate the effect of one anti-pattern from other patterns is important. We propose longitudinal studies to compare similar projects over time. This will help researchers estimate what would have happened without the anti-pattern and to attribute identified impacts to specific patterns. Also, understanding who bears the costs is crucial, since sustainability harm is rarely distributed equally across stakeholders. V. C ONCLUSION In this paper, we have introduced the concept of sustainability anti-patterns in software engineering. As we exemplified, sustainability anti-patterns are beyond localized problems; they are recurring socio-technical patterns that systematically produce long-term unsustainable outcomes across sustainability dimensions. Without a concept for analyzing such phenomena, current research is not able to explicitly capture cross-level interactions and will continue treating symptoms while underlying anti-patterns persist. We are convinced that, in addition to optimizing isolated problems (e.g., energy, maintainability), it is also important in software-engineering practice and research to understand how these problems interact and reinforce each other over time to enable systemic intervention. This need is amplified in the context of AI-assisted development and agentic systems, where the speed and automation of decisionmaking can accelerate the emergence of long-term unsustainable outcomes while also making them harder to trace. As guidance, we outlined a research roadmap for identifying, formalizing, detecting, intervening on, and measuring the impact of sustainability anti-patterns. By tackling the research directions we have proposed, we aim to advance software engineering research and practice toward a more integrated and actionable understanding of sustainability. Acknowledgements This research is supported by the European Union under the project InterGrad-EGD (9110110301). R EFERENCES [1] P. Avgeriou, P. Kruchten, R. L. Nord, I. Ozkaya, and C. Seaman, “Reducing friction in software development,” IEEE Software, vol. 33, no. 1, pp. 66–73, 2016. [2] G. Baxter and I. Sommerville, “Socio-technical systems: From design methods to systems engineering,” Interacting with Computers, vol. 23, no. 1, pp. 4–17, 2011. [3] C. Becker, R. Chitchyan, L. Duboc, S. Easterbrook, B. Penzenstadler, N. Seyff, and C. C. Venters, “Sustainability design and software: The karlskrona manifesto,” in Proc. Int. Conf. Softw. Eng. (ICSE), 2015, pp. 467–476. [4] P. Brada and P. Picha, “Software process anti-patterns catalogue,” in Proc. Eur. Conf. Pattern Languages of Programs (EuroPLoP), 2019. [5] W. J. Brown, R. C. Malveau, H. W. McCormick III, and T. J. Mowbray, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, 1998. [6] R. Chitchyan, C. Becker, S. Betz, L. Duboc, B. Penzenstadler, N. Seyff, and C. C. Venters, “Sustainability design in requirements engineering: State of practice,” in Proc. Int. Conf. Softw. Eng. Companion (ICSE-C), 2016, pp. 533–542.

[7] W. Cunningham, “The WyCash portfolio management system,” in Addendum Proc. ACM OOPSLA, 1992, pp. 29–30. [8] L. Duboc, B. Penzenstadler, J. Porras, A. Sëmman, R. Chitchyan, O. Leifler, S. Betz, and C. C. Venters, “Requirements engineering for sustainability: an awareness framework for designing software systems for a better tomorrow,” Requirements Engineering, vol. 25, no. 4, pp. 469–492, 2020. [9] M. Fowler, Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. [10] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [11] G. A. Garcı́a-Mireles, M. A. Moraga, F. Garcı́a, and C. Calero, “Sustainability in the field of software engineering: A tertiary study,” ACM Transactions on Software Engineering and Methodology, vol. 35, no. 5, 2026. [12] S. Georgiou, S. Rizou, and D. Spinellis, “Software development lifecycle for energy efficiency: Techniques and tools,” ACM Computing Surveys, vol. 52, no. 4, 2019. [13] C. König, D. J. Lang, and I. Schaefer, “Sustainable software engineering: Concepts, challenges, and vision,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 5, 2025. [14] S. Kosbar and M. Hamdaqa, “Smells-sus: Sustainability smells in iac,” in Proc. IEEE/ACM Int. Conf. Mining Softw. Repos. (MSR), 2025, pp. 801–812. [15] K. Lano, Z. Rahman, and L. Alwakeel, “Design patterns for software sustainability,” in Proc. IEEE/ACM Int. Conf. Mining Softw. Repos. (MSR), 2025. [16] S. McGuire, E. Schultz, B. Ayoola, and P. Ralph, “Sustainability is stratified: Toward a better theory of sustainable software engineering,” in Proc. Int. Conf. Softw. Eng. (ICSE), 2023, pp. 1996–2008. [17] A. C. Moises, A. Malucelli, and S. Reinehr, “Practices of energy consumption for sustainable software engineering,” in Proc. IEEE Int. Conf. Softw. Maintenance Evol. (ICSME), 2018, pp. 1–6. [18] A. Moreira, P. Lago, R. Heldal, S. Betz, I. Brooks, R. Capilla, V. C. Coroamă, L. Duboc, J. a. P. Fernandes, O. Leifler, N.-T. Nguyen, S. Oyedeji, B. Penzenstadler, A.-K. Peters, J. Porras, and C. C. Venters, “A roadmap for integrating sustainability into software engineering education,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 5, 2025. [19] H. Noman, N. Mahoto, S. Bhatti, A. Rajab, and A. Shaikh, “Towards sustainable software systems: A software sustainability analysis framework,” Information and Software Technology, vol. 171, 2024. [20] F. Palomba, D. Di Nucci, A. Panichella, A. Zaidman, and A. De Lucia, “On the impact of code smells on the energy consumption of mobile applications,” Information and Software Technology, vol. 105, pp. 43– 55, 2019. [21] B. Penzenstadler, “Where attention goes, energy flows: enhancing individual sustainability in software engineering,” in Proc. Int. Conf. ICT Sustainability (ICT4S), 2020. [22] B. Penzenstadler, L. Duboc, C. C. Venters, S. Betz, N. Seyff, R. Chitchyan, C. Knieriemen, and C. Becker, “Software engineering for sustainability: Find the leverage points!” IEEE Software, vol. 35, no. 4, pp. 22–33, 2018. [23] B. Richmond, “Systems thinking: critical thinking skills for the 1990s and beyond,” System Dynamics Review, vol. 9, no. 2, pp. 113–133, 1993. [24] G. Sriraman and S. Raghunathan, “A systems thinking approach to improve sustainability in software engineering—a grounded capability maturity framework,” Sustainability, vol. 15, no. 11, 2023. [25] D. A. Tamburri, P. Kruchten, P. Lago, and H. van Vliet, “What is social debt in software engineering,” in Proc. Int. Workshop Cooperative Human Aspects Softw. Eng. (CHASE), 2013, pp. 93–96. [26] B. Tanveer, “Sustainable software engineering - have we neglected the software engineer’s perspective?” in Proc. IEEE/ACM Int. Conf. Automated Softw. Eng. Workshops (ASEW), 2021, pp. 267–270. [27] C. C. Venters, R. Capilla, S. Betz, B. Penzenstadler, T. Crick, S. Crouch, E. Y. Nakagawa, C. Becker, and C. Carrillo, “Software sustainability: Research and practice from a software architecture viewpoint,” Journal of Systems and Software, vol. 138, pp. 174–188, 2018. [28] N. Voulvoulis, T. Giakoumis, C. Hunt, V. Kioupi, N. Petrou, I. Souliotis, C. Vaghela, and W. I. H. b. Wan Rosely, “Systems thinking as a paradigm shift for sustainability transformation,” Global Environmental Change, vol. 75, p. 102544, 2022.

Related documents

• No One Left Behind: Cross-Level Analysis for Sustainable Software Engineering#926738
• Foundations of Software Engineering#67196
• Foundations and Frontiers in Software Engineering : Proceedings of 15th Computer Science On-line Conference 2026, Volume 1 / edited by Radek Silhavy, Petr Silhavy#1106360
• SLRMentor: An LLM-Based Tool Supporting Learning of SLR in Software Engineering#267737
• MergeSE: Post-Hoc Model Merging for Software Engineering Tasks Without Retraining#429436