Pith. sign in

REVIEW 4 major objections 4 minor 49 references

Smells-sus: Sustainability Smells in IaC

T0 review · 4 major / 4 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper defines seven sustainability smells in Terraform scripts, validates them through a practitioner survey, and measures their prevalence in 28,327 open-source scripts, finding Monolithic Infrastructure in 9.67% of scripts.

desk verdict A useful first taxonomy of sustainability smells in Terraform, but the headline prevalence numbers rest on an underspecified regex detector and an inconsistent dataset count. read the letter →

arxiv 2501.07676 v2 pith:OQM6QHOZ submitted 2025-01-13 cs.SE cs.DCcs.NI

Seif Kosbar , Mohammad Hamdaqa This is my paper · ORCID
classification cs.SEcs.DCcs.NI
keywords sustainabilitysmellsInfrastructureasCodeTerraformanti-patternscloudempiricalsoftwareengineeringresourceefficiency
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that Infrastructure as Code scripts, specifically Terraform, contain recurring anti-patterns that undermine cloud sustainability, and that these anti-patterns can be named, recognized, and counted. It extracts sustainability best practices from AWS, Azure, and GCP guidance, converts each into an anti-pattern that it calls a sustainability smell, confirms with 19 practitioners that the patterns count as bad practice, and measures how often seven defined smells appear in a large corpus. The headline empirical result is that the most prevalent smell, Monolithic Infrastructure, appears in 9.67% of scripts, while the other six are far rarer. A sympathetic reader would care because the study turns vague sustainability concerns into concrete, detectable code-level patterns that practitioners and tooling can target.

What carries the argument

The central machinery is the sustainability smell concept, transferred from code smells to IaC: a recurring code pattern or deployment choice that violates cloud-provider sustainability guidance. The identification pipeline uses grounded theory on sustainability reports from AWS, Azure, and GCP, producing four attributes, Runtime Dependency, Resource Context, Code Dependency, and Inherent Badness, that categorize the smells. Those attributes feed a binary similarity matrix and hierarchical clustering, which divides the smells into General, Demand, and Application categories. Prevalence is measured with hand-built regex patterns for each smell, refined through iterative testing and manually validated on a random sample with reported 100% accuracy.

What would settle it

Measure, for matched pairs of Terraform configurations that differ only in one smell (for example, auto-scaling enabled versus disabled), the actual cloud bill or energy use over a representative workload; if the smelly configuration is not systematically more expensive or energy-hungry than the clean one, the central claim that these patterns are sustainability problems would collapse.

Watch

Extended reading notes

Core claim

The paper's central discovery is a catalog of seven sustainability smells in Terraform: Over-Provisioning Resources, Lack of Auto-Scaling, Ignoring Resource Lifecycles, Excessive Logging, Unoptimized Data Transfers, State Management, and Monolithic Infrastructure. Each smell is derived by taking a sustainability best practice from AWS, Azure, or GCP and positing the corresponding anti-pattern, that is, a failure to follow the guidance. The study reports that a survey of 19 IaC practitioners widely recognizes most of these patterns as bad practice, with agreement ranging from 47.4% to 94.7%, and that a regex-based scan of 28,327 Terraform scripts finds Monolithic Infrastructure by far the most common at 9.67%, followed by State Management at 1.59% and Lack of Auto-Scaling at 0.73%. The paper concludes that these smells often arise from a combination of script structure, configuration choices, and deployment context, which makes root-cause analysis difficult.

Load-bearing premise

The load-bearing premise is that a Terraform pattern counts as a sustainability smell when it deviates from a best practice in AWS, Azure, or GCP sustainability guidance, without direct measurement that the deviation actually increases energy use or cost.

Editorial extensions

If this is right

  • If the catalog is correct, Terraform repositories can be automatically screened for these seven patterns, with Monolithic Infrastructure as the highest-yield target.
  • The three-category structure implies that mitigation strategies differ: demand smells require workload data, general smells can be addressed through modular design, and application smells require inspecting the code the infrastructure runs.
  • The very low observed prevalence of Over-Provisioning Resources, 0.01%, suggests either that open-source Terraform scripts rarely over-provision or that the regex detector under-recognizes the pattern, so the reported rates are best treated as lower-bound estimates.
  • The 9.67% figure for Monolithic Infrastructure gives a concrete baseline that future IaC sustainability tools and studies can compare against.
  • Because the survey shows weaker consensus for Ignoring Resource Lifecycles and State Management, those two smells are the ones most in need of further evidence before being treated as established sustainability problems.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the study measures pattern frequencies and practitioner opinions rather than energy or cost, the actual sustainability impact of the seven smells remains unquantified; a natural next step is pairing each smell with billing or energy telemetry to test whether removal actually reduces resource use.
  • The binary similarity matrix treats attribute matches as all-or-nothing, so using graded similarity or continuous features could reveal overlaps among smells that the current three categories hide.
  • The reported prevalence depends on regex patterns, so smells expressed through varied syntax, such as auto-scaling configured outside the scanned file, may be undercounted; a parser-based detector on the same dataset would be a direct check.
  • Because the smells were derived only from AWS, Azure, and GCP guidance, applying the same method to other IaC tools like Ansible or to other providers could yield a different or extended catalog.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper defines seven 'sustainability smells' for Terraform Infrastructure-as-Code scripts, grounded in a grounded-theory analysis of AWS, Azure, and GCP sustainability best practices. It validates the smells through a 19-participant practitioner survey and measures their prevalence in a dataset of 28,327 Terraform scripts using regex-based detection. The headline result is that Monolithic Infrastructure (SS7) appears in 9.67% of scripts, followed by State Management (SS6) at 1.59% and Lack of Auto-Scaling (SS2) at 0.73%. The paper also clusters the smells into three categories and derives practical recommendations.

Significance. If the results hold, the paper provides a useful initial taxonomy of sustainability-related anti-patterns in Terraform and the first large-scale prevalence estimates for such patterns. Strengths include the grounding in external cloud-provider best practices, the use of two independent raters with perfect inter-rater agreement, a replication package, and a survey that gives some practitioner perspective. The contribution is weakened, however, by the lack of any direct energy or cost measurement, an unquantified regex detector, and an internal inconsistency in the reported dataset size. The prevalence numbers are therefore best interpreted as preliminary and would need to be substantiated before the paper's central empirical claims can be accepted.

major comments (4)
  1. [Abstract, §3.5] The dataset size is internally inconsistent: the abstract reports 395 open-source repositories, while Section 3.5 reports 812 distinct GitHub repositories (401 AWS, 137 Azure, 274 GCP). Because the repository count is used as the sampling strata and the denominator for prevalence claims, this discrepancy must be resolved and the correct number stated explicitly in both the abstract and Section 3.5.
  2. [§3.6, §4.3] The prevalence figures in Section 4.3 rest on an unquantified regex detector. The paper states that the regex-based method achieved 100% accuracy based on random sampling manual validation, but it reports neither the number of manually reviewed detections per smell nor any recall estimate, and the regex patterns are not included in the manuscript. For SS7 (Monolithic Infrastructure), Table 2 shows only a comment '# Many more resources follow ...' with no explicit rule or threshold. As a result, the headline 9.67% prevalence for SS7 is not reproducible or verifiable from the information given; the detection rules and validation sample sizes must be reported.
  3. [§3.6] The detection patterns were iteratively refined on a subset of the same dataset that is later used to measure prevalence, and the manual validation is drawn from the scripts already flagged by those patterns. This procedure can overfit to the dataset and inflate precision; the manuscript does not report the size of the refinement subset, the number of validation iterations, or how the random validation sample was constructed. These details are needed to assess the uncertainty of the RQ3 numbers.
  4. [§3.2, §7.2] The central premise of the smell definition is that each cloud-provider best practice has a corresponding anti-pattern whose presence indicates a sustainability problem. The paper does not measure energy consumption, cost, or carbon impact; its support is practitioner perception from a 19-participant survey. Section 7.2 explicitly concedes that removing these smells 'may not necessarily result in significant reductions in energy consumption or cost.' This limitation is load-bearing for the claim that the identified patterns are sustainability smells and should be stated in the abstract and conclusion, not only in threats to validity.
minor comments (4)
  1. [Table 2] The code samples in Table 2 contain character-spacing artifacts (e.g., 're so ur ce' instead of 'resource') that make them difficult to read; please use a monospaced font with proper ASCII text.
  2. [Figure 5] Figure 5 presents prevalence bars without confidence intervals or raw counts; even after the detector is specified, adding the counts and, where possible, confidence intervals would help interpret the rates.
  3. [§3.4] The survey had only 19 participants and the paper reports percentages such as 94.7% (SS1) without absolute counts; describing the exact recruitment procedure and the number of responses per question would clarify the generalizability of the perception findings.
  4. [§2.2] The claim that no IaC-specific sustainability standards exist is supported by cloud-provider documents, but the text would benefit from citing recent academic work on IaC sustainability, if any, to better position the contribution.

Circularity Check

1 steps flagged · score 2.0 of 10

Mild circularity in the rater-validation step; prevalence claims rest on an unquantified regex detector but are not circular.

  1. self definitional [Section 4.1 (RQ1), sustainability-smell validation paragraph]
    "To validate our identified sustainability smells, we engaged two independent raters who were not involved in this study. These raters, possessing expertise in IaC, were tasked with assessing whether the identified smells corresponded to the associated best practices outlined in industry reports. For this purpose, we supplied the raters with the names of the smells, an example of each, and the corresponding best practice. Each rater independently evaluated the alignment of the smells with the provided best practices."

    The validation supplies the ground truth: raters are given 'the corresponding best practice' for each smell, which is the very association the authors already used when deriving the smell from the cloud-provider documents. The raters' perfect agreement (Kappa = 1.0) therefore only confirms the supplied pairing; it is not independent evidence that the smells correspond to the best practices. The taxonomy itself is externally grounded in AWS, Azure, and GCP materials, so this step is a self-definitional validation rather than a circular derivation of the whole taxonomy.

full rationale

The central taxonomy is not circular: the seven smells are derived from external cloud-provider sustainability documents (AWS Well-Architected Sustainability Pillar, Azure and GCP guidance) via grounded-theory coding, and the RQ2 validation relies on an independent 19-practitioner survey rather than on the authors' own definitions. The prevalence measurements (RQ3) are computed by regex detection; although the regex patterns were iteratively refined on a subset of the same dataset and the paper reports only precision-based '100% accuracy' without recall or sample sizes, this is a measurement-support weakness, not a reduction by construction: the prevalence set (26,467 scripts) is claimed to be separate from the 1,860-script qualitative sample, and the smell definitions come from external best practices, not from the regex output. The one concrete circular step is the rater validation in Section 4.1, where raters were supplied with the 'corresponding best practice' for each smell, so their perfect agreement merely confirms the authors' pre-assigned mapping. The paper itself acknowledges in Section 7.2 that removing these smells may not reduce energy or cost, further showing that the sustainability-impact claim is not hidden inside the definitions. No load-bearing self-citation chain exists; the abstract's 395-repository count also conflicts with Section 3.5's 812 repositories, but that is an internal-consistency issue, not circularity.

Assumptions & free parameters 3 free parameters · 4 assumptions · 7 invented entities

The taxonomy is grounded in external best practices and a small survey, but the prevalence numbers depend on hand-tuned regex patterns and a dataset with an unresolved repository count discrepancy (395 vs 812). The seven smells are new constructs with no direct energy or cost validation.

free parameters (3)
  • Regex patterns and detection thresholds for each smell = Not fully specified in paper
    Prevalence depends on hand-crafted regexes, e.g., retention_in_days=365 for SS4; refined iteratively on dataset subsets (Section 3.6).
  • Smell attribute assignments (Table 3) = 0/1 matrix
    The similarity matrix and hierarchical clustering rely on author-assigned attribute values for each smell.
  • Repository popularity threshold = At least 2 stars
    Dataset composition and external validity depend on this filtering choice (Section 3.5).
assumptions (4)
  • domain assumption Cloud provider best practices from AWS, Azure, and GCP are valid and sufficient sources for defining sustainability in IaC.
    The entire taxonomy is derived from these documents via grounded theory (Section 3.1).
  • domain assumption The qualitative coding of 1,860 scripts reached theoretical saturation and correctly maps anti-patterns to code patterns.
    Authors claim saturation after iterative coding (Section 3.1), but this is a subjective qualitative judgment.
  • domain assumption GitHub repository filtering criteria yield a representative sample of real-world Terraform usage.
    Filters exclude forks, tutorials, course assignments, and low-star repositories (Section 3.5), which can bias prevalence.
  • domain assumption Survey responses from 19 practitioners validate the practical relevance of the defined smells.
    The survey is small and non-random (Section 3.4), yet used as validation evidence.
invented entities (7)
  • SS1: Over-Provisioning Resources
    purpose: Captures allocation of more resources than needed
    No direct energy or cost measurement; only practitioner survey and code pattern examples.
  • SS2: Lack of Auto-Scaling
    purpose: Captures static resource allocation that ignores workload fluctuations
    No direct energy or cost measurement; only practitioner survey and code pattern examples.
  • SS3: Ignoring Resource Lifecycles
    purpose: Captures failure to manage resource creation and destruction policies
    No direct energy or cost measurement; only practitioner survey and code pattern examples.
  • SS4: Excessive Logging
    purpose: Captures unnecessary detailed logging and long retention periods
    No direct energy or cost measurement; only practitioner survey and code pattern examples.
  • SS5: Unoptimized Data Transfers
    purpose: Captures cross-region or inefficient data movement between resources
    No direct energy or cost measurement; only practitioner survey and code pattern examples.
  • SS6: State Management
    purpose: Captures poor Terraform state handling, such as lack of remote backends
    No direct energy or cost measurement; only practitioner survey and code pattern examples.
  • SS7: Monolithic Infrastructure
    purpose: Captures single-file configurations that reduce modularity and scalability
    No direct energy or cost measurement; only practitioner survey and code pattern examples.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Smells-sus: Sustainability Smells in IaC." pith.science (2026). https://pith.science/paper/OQM6QHOZ

@misc{pith2026250107676,
  author       = {Pith},
  title        = {Pith review of: Smells-sus: Sustainability Smells in IaC},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OQM6QHOZ}},
  note         = {Machine review of arXiv:2501.07676}
}
read the original abstract

Practitioners use Infrastructure as Code (IaC) scripts to efficiently configure IT infrastructures through machine-readable definition files. However, during the development of these scripts, some code patterns or deployment choices may lead to sustainability issues like inefficient resource utilization or redundant provisioning for example. We call this type of patterns sustainability smells. These inefficiencies pose significant environmental and financial challenges, given the growing scale of cloud computing. This research focuses on Terraform, a widely adopted IaC tool. Our study involves defining seven sustainability smells and validating them through a survey with 19 IaC practitioners. We utilized a dataset of 28,327 Terraform scripts from 395 open-source repositories. We performed a detailed qualitative analysis of a randomly sampled 1,860 Terraform scripts from the original dataset to identify code patterns that correspond to the sustainability smells and used the other 26,467 Terraform scripts to study the prevalence of the defined sustainability smells. Our results indicate varying prevalence rates of these smells across the dataset. The most prevalent smell is Monolithic Infrastructure, which appears in 9.67\% of the scripts. Additionally, our findings highlight the complexity of conducting root cause analysis for sustainability issues, as these smells often arise from a confluence of script structures, configuration choices, and deployment contexts.

Figures

Figures reproduced from arXiv: 2501.07676 by the authors.

Figure 1
Figure 1. Overview of The Research Methodology 2.3 Code Smells Code smells, a concept popularized by Martin Fowler in his seminal book “Refactoring: Improving the Design of Existing Code" [10] which refer to any characteristic in the source code that suggests deeper issues, even though they do not prevent the program from functioning. These smells signal the need for refactoring to improve maintainability, readability, and qu… view at source ↗
Figure 2
Figure 2. Hierarchical Clustering Dendrogram for Sustainability Smells [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Survey participants YOE using IaC tools dendrogram, each leaf represents an individual sustainability smell. As we move up, nodes represent clusters formed by merging pairs of smells or clusters. Based on the dendrogram we can interpret the clustering results as follows: • Category 1: General Sustainability Smells: Can be considered the rule of thumb (SS3, SS4, SS6, SS7). • Category 2: Demand Sustainability Smells: … view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Survey Participants Perception of Sustainability Smells [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]
Figure 5
Figure 5. Figure 5: Percentage of Terraform Files with Specific Sustainability Smells [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 44 canonical work pages

  1. [1]

    Data Centres & Networks,

    International Energy Agency (IEA), “Data Centres & Networks,” Mar. 2024. [Online]. Available:https://www. iea.org/energy-system/buildings/data-centres-and-data-transmission-networks

    work page 2024

  2. [3]

    Humble and D

    J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley Professional, 2010

    work page 2010

  3. [4]

    Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Industry,

    M. Guerriero et al., “Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Industry,” in Proc. IEEE International Conference on Software Maintenance and Evolution (ICSME), 2019, pp. 580-589. doi: 10.1109/ICSME.2019.00092

    arXiv 2019

  4. [5]

    Performance Comparison of Terraform and Cloudify as Multicloud Orchestrators,

    L. R. de Carvalho and A. P. F. de Araujo, “Performance Comparison of Terraform and Cloudify as Multicloud Orchestrators,” in Proc. IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID), 2020, pp. 380-389. doi: 10.1109/CCGrid49817.2020.00-55 13 A PREPRINT - JANUARY 22, 2025

    arXiv 2020

  5. [6]

    Configuration | Cloud Deployment Manager Documentation,

    Google Cloud, “Configuration | Cloud Deployment Manager Documentation,” 2023. [Online]. Available: https: //cloud.google.com/deployment-manager/docs/configuration

    work page 2023

  6. [7]

    Terraform Documentation,

    HashiCorp, “Terraform Documentation,” 2023. [Online]. Available: https://developer.hashicorp.com/ terraform

    work page 2023

  7. [8]

    Amazon Web Services (AWS), Sustainability Pillar AWS well-architected framework - sustainabil- ity pillar, Oct. 2023. [Online]. Available: https://docs.aws.amazon.com/wellarchitected/latest/ sustainability-pillar/sustainability-pillar.html

    work page 2023

  8. [9]

    How to adapt applications for the Cloud environment: Challenges and solutions in migrating applications to the Cloud,

    V . Andrikopoulos et al., “How to adapt applications for the Cloud environment: Challenges and solutions in migrating applications to the Cloud,” Computing, vol. 95, no. 6, pp. 493–535, Dec. 2012. doi: 10.1007/s00607-012- 0248-2

    work page doi:10.1007/s00607-012- 2012

Show all 49 references
  1. [10]

    Fowler, Refactoring: Improving the Design of Existing Code , Addison-Wesley, 1999

    M. Fowler, Refactoring: Improving the Design of Existing Code , Addison-Wesley, 1999

    1999

  2. [11]

    Code Smells,

    Refactoring Guru, “Code Smells,” [Online]. Available: https://refactoring.guru/refactoring/smells. Accessed: 2024-06-28

    2024

  3. [12]

    Amazon Web Services in Action,

    A. Wittig and M. Wittig, “Amazon Web Services in Action,” 1st ed. USA: Manning Publications Co., 2015

    2015

  4. [13]

    Infrastructure as Code: DevOps Best Practices with Microsoft Azure,

    Microsoft and Forrester, “Infrastructure as Code: DevOps Best Practices with Microsoft Azure,” Apr. 2015. [Online]. Available: https://devops.com/wp-content/uploads/2015/04/ Microsoft-Forrester-Infra-as-code-TLP_April_2015.pdf . Accessed: 2024-06-28

    2015

  5. [14]

    Magic Quadrant for Cloud Infrastructure as a Service,

    Gartner, “Magic Quadrant for Cloud Infrastructure as a Service,” 2014. [Online]. Available: https://www. gartner.com/en/documents/2571419. Accessed: 2024-06-28

    2014

  6. [15]

    Terraform by HashiCorp,

    HashiCorp, “Terraform by HashiCorp,” [Online]. Available:https://www.terraform.io/. Accessed: 2024- 06-28

    2024

  7. [16]

    Terraform Configuration Syntax,

    HashiCorp, “Terraform Configuration Syntax,” [Online]. Available: https://developer.hashicorp.com/ terraform/language/syntax/configuration. Accessed: 2024-06-28

    2024

  8. [17]

    Comparing Terraform, Chef, and Puppet,

    HashiCorp, “Comparing Terraform, Chef, and Puppet,” [Online]. Available:https://developer.hashicorp. com/terraform/intro/vs/chef-puppet. Accessed: 2024-07-28

    2024

  9. [18]

    The Terraform Book,

    J. Turnbull, “The Terraform Book,” Turnbull Press, Nov. 2016

    2016

  10. [19]

    Design for environmental sustainability | google cloud,

    Google, “Design for environmental sustainability | google cloud,” [Online]. Available: https://cloud.google. com/architecture/framework/sustainability

  11. [20]

    Cost Optimization - Microsoft Azure Well-Architected Framework,

    Microsoft, “Cost Optimization - Microsoft Azure Well-Architected Framework,” 2024. [Online]. Available: https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/

    2024

  12. [21]

    Hexmoor, Computational Network Science: An Algorithmic Approach , Morgan Kaufmann Publishers Inc., 2014

    H. Hexmoor, Computational Network Science: An Algorithmic Approach , Morgan Kaufmann Publishers Inc., 2014

    2014

  13. [22]

    Cost Optimization - Alibaba Cloud Well-Architected Framework,

    Alibaba Cloud, “Cost Optimization - Alibaba Cloud Well-Architected Framework,” 2024. [Online]. Available: https://www.alibabacloud.com/help/en/well-architected/latest/cost-optimization-1

    2024

  14. [23]

    Hierarchical Clustering,

    F. Nielsen, “Hierarchical Clustering,” in Undergraduate Topics in Computer Science , Springer International Publishing, 2016, pp. 195–211. doi: 10.1007/978-3-319-21903-5_8

    2016 doi

  15. [24]

    A Novel Cost Based Model for Energy Consumption in Cloud Computing,

    A. Horri and Gh. Dastghaibyfard, “A Novel Cost Based Model for Energy Consumption in Cloud Computing,” The Scientific World Journal, vol. 2015, pp. 1–10, 2015. doi: 10.1155/2015/724524

    2015 doi

  16. [25]

    Variance reduction in Monte Carlo via the median of adaptive weights,

    Z. Botev and A. Ridder, “Variance reduction in Monte Carlo via the median of adaptive weights,” Journal of the American Statistical Association, vol. 112, no. 517, pp. 1318–1329, 2017. doi: 10.1080/01621459.2016.1260469

    2017

  17. [26]

    Sustainability is stratified: Toward a better theory of sustainable software engineering,

    S. McGuire, E. Schultz, B. Ayoola, and P. Ralph, “Sustainability is stratified: Toward a better theory of sustainable software engineering,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) , 2023, pp. 1996–2008. IEEE

    2023

  18. [27]

    Integrated framework for incorporating sustainability design in software engineering life-cycle: An empirical study,

    T. R. D. Saputri and S.-W. Lee, “Integrated framework for incorporating sustainability design in software engineering life-cycle: An empirical study,” Information and Software Technology , vol. 129, p. 106407, 2021. Elsevier

    2021

  19. [28]

    Exploring the Carbon Footprint of Hugging Face’s ML Models: A Repository Mining Study,

    J. Castaño, S. Martínez-Fernández, X. Franch, and J. Bogner, “Exploring the Carbon Footprint of Hugging Face’s ML Models: A Repository Mining Study,” in 2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2023, pp. 1–12. IEEE

    2023

  20. [29]

    An exploratory literature study on sharing and energy use of language models for source code,

    M. Hort, A. Grishina, and L. Moonen, “An exploratory literature study on sharing and energy use of language models for source code,” in 2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2023, pp. 1–12. IEEE. 14 A PREPRINT - JANUARY...

    2023

  21. [30]

    Which design decisions in AI-enabled mobile applications contribute to greener AI?,

    R. C. Castanyer, S. Martínez-Fernández, and X. Franch, “Which design decisions in AI-enabled mobile applications contribute to greener AI?,” Empirical Software Engineering, vol. 29, no. 1, p. 2, 2024. Springer

    2024

  22. [31]

    Energy Patterns for Web: An Exploratory Study,

    P. Rani, J. Zellweger, V . Kousadianos, L. Cruz, T. Kehrer, and A. Bacchelli, “Energy Patterns for Web: An Exploratory Study,” in Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Society, 2024, pp. 12–22

    2024

  23. [32]

    Glitch: Automated polyglot security smell detection in infrastructure as code,

    N. Saavedra and J. F. Ferreira, “Glitch: Automated polyglot security smell detection in infrastructure as code,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering , 2022, pp. 1–12

    2022

  24. [33]

    Security smells in ansible and chef scripts: A replication study,

    A. Rahman, M. R. Rahman, C. Parnin, and L. Williams, “Security smells in ansible and chef scripts: A replication study,” ACM Transactions on Software Engineering and Methodology (TOSEM) , vol. 30, no. 1, pp. 1–31, 2021. ACM

    2021

  25. [34]

    The seven sins: Security smells in infrastructure as code scripts,

    A. Rahman, C. Parnin, and L. Williams, “The seven sins: Security smells in infrastructure as code scripts,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) , 2019, pp. 164–175. IEEE

    2019

  26. [35]

    Toward a catalog of software quality metrics for infrastructure code,

    S. Dalla Palma, D. Di Nucci, F. Palomba, and D. A. Tamburri, “Toward a catalog of software quality metrics for infrastructure code,” Journal of Systems and Software , vol. 170, p. 110726, 2020. Elsevier

    2020

  27. [36]

    An empirical study of code smells in transformer-based code generation techniques,

    M. L. Siddiq, S. H. Majumder, M. R. Mim, S. Jajodia, and J. C. S. Santos, “An empirical study of code smells in transformer-based code generation techniques,” in 2022 IEEE 22nd International Working Conference on Source Code Analysis and Manipulation (SCAM) , 2022, pp. 71–82. IEEE

    2022

  28. [37]

    Mining for cost awareness in the infrastructure as code artifacts of cloud-based applications: An exploratory study,

    D. Feitosa, M.-T. Penca, M. Berardi, R.-D. Boza, and V . Andrikopoulos, “Mining for cost awareness in the infrastructure as code artifacts of cloud-based applications: An exploratory study,”Journal of Systems and Software, p. 112112, 2024. Elsevier

    2024

  29. [38]

    & Fernandez-Sanz, L

    Gupta, A., Suri, B., Sharma, D., Misra, S. & Fernandez-Sanz, L. Code smells analysis for android applications and a solution for less battery consumption. Sci. Rep.. 14, 17683 (2024,7)

    2024

  30. [39]

    Cost-effective Strategies for Building Energy Efficient Mobile Applications

    Bangash, A. Cost-effective Strategies for Building Energy Efficient Mobile Applications. 2023 IEEE/ACM 45th International Conference On Software Engineering: Companion Proceedings (ICSE-Companion) . pp. 281-285 (2023,5), http://dx.doi.org/10.1109/ICSE-Companion58688.2023.00076

    2023

  31. [40]

    & Niazi, M

    Mumtaz, H., Alshayeb, M., Mahmood, S. & Niazi, M. A survey on <scp>UML</scp> model smells detection techniques for software refactoring. Journal Of Software: Evolution And Process . 31 (2019,2), http://dx.doi. org/10.1002/smr.2154

    2019 doi

  32. [41]

    & Hamou-Lhadj, A

    Panahandeh, M., Hamdaqa, M., Zamani, B. & Hamou-Lhadj, A. MUPPIT: a method for using proper patterns in model transformations. Software And Systems Modeling. 20, 1491-1523 (2021,1), http://dx.doi.org/10. 1007/s10270-020-00853-y

    2021

  33. [42]

    Yujuan Jiang and Bram Adams. 2015. Co-evolution of infrastructure and source code: an empirical study. In Proceedings of the 12th Working Conference on Mining Software Repositories (MSR ’15). IEEE Press, 45–55

    2015

  34. [43]

    Incident documentation/20170118-Labs

    Commons, W. Incident documentation/20170118-Labs. (2017), https://wikitech.wikimedia.org/wiki/ Incident_documentation/20170118-Labs, [Online; accessed 27-Jan-2019]

    2017

  35. [44]

    Amazon And The 150 Million Dollar Typo

    Hersher, R. Amazon And The 150 Million Dollar Typo. (2017), https://www.npr.org/sections/ thetwo-way/2017/03/03/518322734/amazon-and-the-150-million-typo , [Online; accessed 27-Jan- 2019]

    2017

  36. [45]

    & DeFranco, J

    Neill, C., Laplante, P. & DeFranco, J. Antipatterns: Managing Software Organizations and People. (CRC Press, 2011)

    2011

  37. [46]

    & Strauss, A

    Corbin, J. & Strauss, A. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. (Sage Publications, 2014)

    2014

  38. [47]

    (2024,11), https://docs.aws

    Amazon Web Services Security Pillar - AWS Well-Architected Framework. (2024,11), https://docs.aws. amazon.com/wellarchitected/latest/security-pillar/welcome.html, Accessed: 2024-11-07

    2024

  39. [48]

    (2024,10), https: //cloud.google.com/architecture/framework/security, Accessed: 2024-11-07

    Google Cloud Google Cloud Architecture Framework: Security, Privacy, and Compliance. (2024,10), https: //cloud.google.com/architecture/framework/security, Accessed: 2024-11-07

    2024

  40. [49]

    (2024,11), https://learn

    Microsoft Security Quick Links - Microsoft Azure Well-Architected Framework. (2024,11), https://learn. microsoft.com/en-us/azure/well-architected/security/ , Accessed: 2024-11-11 15

    2024

  41. [2023]

    Available: https://arxiv.org/abs/2303.10572

    [Online]. Available: https://arxiv.org/abs/2303.10572

    arXiv

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.