• Information For
    • Computational Molecular Sciences Community
    • Environmental System Science Community
    • Exascale Computing Community
    • Scientific Libraries Community
    • Software Engineering Community
    • Community of Supercomputer Facilities and their Users
  • Contribute to BSSw
  • Receive Our Email Digest
  • Contact BSSw
  • Information For
    Computational Molecular Sciences Community Environmental System Science Community Exascale Computing Community Scientific Libraries Community Software Engineering Community Community of Supercomputer Facilities and their Users
  • Contribute to BSSw
  • Receive Our Email Digest
  • Resources

    Better

    Planning

    • Software Process Improvement
    • Software Engineering
    • Requirements
    • Design
    • Software Interoperability

    Better

    Development

    • Documentation
    • Configuration and Builds
    • Revision Control
    • Release and Deployment
    • Issue Tracking
    • Programming Languages
    • Development Tools
    • Refactoring

    Better

    Performance

    • High-Performance Computing (HPC)
    • Performance at Leadership Computing Facilities
    • Performance Portability

    Better

    Reliability

    • Testing
    • Continuous Integration Testing
    • Reproducibility
    • Debugging

    Better

    Collaboration

    • Projects and Organizations
    • Strategies for More Effective Teams
    • Funding Sources and Programs
    • Software Publishing and Citation
    • Licensing
    • Discussion and Question Sites
    • Conferences and Workshops

    Better

    Skills

    • Online Learning
    • Personal Productivity and Sustainability

    View All Resources

    • Better Planning
    • Better Development
    • Better Performance
    • Better Reliability
    • Better Collaboration
    • Better Skills
    • View All Resources
  • Blog
  • Events
  • About
    • Team
    • Policies and Code of Conduct
    • BSSw Fellowship Program
  • Home
  • Blog
  • When Not to Use Agile in Scientific Software...

When Not to Use Agile in Scientific Software Development

Share on LinkedIn Share on Facebook Tweet Copied! Permalink

PublishedFeb 12, 2021
Author Anshu Dubey
TOPICS
Better Planning
Software Engineering
Better Development
Refactoring

Using Agile principles in the development of scientific software is widely accepted as a best practice. But in some situations, a deeper initial dive into requirements and design can be beneficial.

Agile principles in science vs enterprise software

Over the past few years, it has almost become an orthodoxy among better-informed scientific software developers to follow Agile principles in their software processes. Several reasons have driven this scenario. Initially, the models that dominated enterprise software before the advent of Agile methods had far too many process overheads to be even remotely feasible in science environments. More important, two key ideologies coincided with one another: the growing popularity of Agile principles in enterprise software and the scientific software community's growing awareness of the adverse impact on productivity in the absence of defined software processes. However, the ways in which the adoption of Agile principles have affected these two areas of software development could not be more different.

In enterprise software, Agile methods have served to reduce the upfront overheads and made processes more nimble. In most science domains, the software development process has traditionally resembled dysfunctional Agile, in the sense that the development was driven by results needed for the next science paper. The emphasis was on quick development and availability to the "client," who was often the developers themselves. The flip side was that the amount of technical debt accrued through such unplanned development led to the untimely demise of many scientific software projects. So, ironically, the introduction of Agile methods in these scientific domains was doing the exact opposite of what it was doing for enterprise software. That is, Agile methodology was slowing down the next "delivery" of scientific software to incorporate some process where none had existed before.

Is Agile always the right answer?

Over the course of two major version revisions of FLASH, a large and long-lived scientific software project, I have come to the conclusion that while the incorporation of more formal processes as part of Agile has generally been helpful, the evangelization of Agile in the community may have gone too far for some classes of scientific software, in particular multiphysics multidomain codes. For example, because of their mathematical complexity, long-lived multiphysics codes tend to exercise separation of concerns, where bookkeeping is kept separate from the numerics. This approach is driven partly by the interdisciplinary nature of these projects and partly by the highly dynamic world of algorithms used in scientific software. Many multiphysics application software projects rely on a robust framework to enable flexibility and extensibility of the software. As with anything that needs to be robust and has to last a long time, a great deal of thought needs to go into requirements gathering and design. In this instance, Agile methods can be counterproductive. The exploration of the design space itself can follow Agile principles, but the overall design of the framework requires a more holistic approach.

FLASH had been quickly stitched together initially using three pre-existing codes following the "quicker than Agile" approach common in science. Use of Agile would have been appropriate for the first functional version; but once a tool was available to do science, it was equally important to redesign and refactor. The availability of this "quick and dirty" solution permitted a more considered approach to design for longevity. In two instances of major architectural revisions of FLASH that I have been associated with, the design phase took longer than 6 months of discussions, white boarding, prototyping, refining, and even discarding ideas. Both times the architectural revision took more than two years from the start before the first simple application instance could be configured. As a result of this upfront investment in requirements gathering and thoroughly understanding the design space, the code has been able to pivot to several science domains (it was built for astrophysics, and it is now used by at least six other domains), saving huge infrastructure development efforts in those domains.

Software processes should fit the needs

As with everything else in the world, process should fit needs. Where modifications impact a lot of code, making the cost of modifications high, but where the rate of change is very low, more thorough planning is called for. On the other hand, where changes are frequent, relatively inexpensive, and local (e.g., some numerical algorithms), Agile is the perfect choice.

Acknowledgement

This blog post was first presented as a whitepaper at the 2020 Collegeville Workshop (CW20).

Author bio

Anshu Dubey is a computational scientist in the Mathematics and Computer Science Division at Argonne National Laboratory and a Senior Scientist in the Department of Computer Science at the University of Chicago. She is the chief software architect for FLASH, a multiphysics, multiscale HPC application that is used by multiple science and engineering domains as their community code. She is interested in all aspects of HPC scientific software, with special emphasis on design, productivity, and sustainability issues.

Comment

More on Software Engineering and Refactoring

Useful Practices for Software Engineering on Medium-Sized Distributed Scientific Projects

Published Feb 25, 2021

By Keith Beattie and Dan Gunter

The RSE-HPC-2020 Workshop: Creating Community, Building Careers, Addressing Challenges

Published Oct 26, 2020

By Charles Ferenbaugh, Sandra Gesing, Simon Hettrick, and Daniel S. Katz

A Community of Practice around Peer Review for Long-Term Research Software Sustainability

Published Aug 28, 2020

By Karthik Ram, Carl Boettiger, Scott Chamberlain, Noam Ross, Maƫlle Salmon, and Stefanie Butland

The Lazy Approach to Developing Scientific Research Software

Published Jun 16, 2020

By Carl Simon Adorf and Vyas Ramasubramani

Making Myself Better: What Craftspeople Can Teach Us about Software

Published May 25, 2020

By Wolfgang Bangerth

Working Remotely: The Spack Team

Published May 16, 2020

By Todd Gamblin and Elaine M. Raybourn

Research Software Engineer Stories

Published Apr 24, 2020

By Vanessasaurus

Maintainers Drive Software Sustainability

Published Apr 14, 2020

By Steven Smith

Scientific Software Projects and Their Communities

Published Mar 23, 2020

By Rene Gassmoeller

Spreading Ideas about Better Scientific Software

Published Feb 28, 2020

By David E. Bernholdt

US Research Software Engineer (US-RSE) Association

Published Jan 15, 2020

By Ian Cosden, Chris Hill, Sandra Gesing, and Charles Ferenbaugh

Hello CSE World

Published Dec 05, 2019

By Heather Switzer, Elsa Gonsiorowski, PhD, and Mark C. Miller

Research Software Engineer: A New Career Track?

Published Jun 14, 2018

By Chris Richardson

Can You Teach an Old Code New Tricks?

Published Mar 26, 2018

By Charles Ferenbaugh

FLASH5 Refactoring and PSIP

Published Aug 27, 2019

By Anshu Dubey and Jared O'Neal

Porting Codes to New Architectures

Published Nov 26, 2018

By Bronson Messer

logo Better Scientific Software
  • BSSw Fellowship Program
  • Policies
  • Site Contributors
  • Contact BSSw
  • Receive Our Email Digest
  • Follow Our RSS Feed

Copyright © 2020 Better Scientific Software under MIT License

United States Department of Energy Office of Science National Nuclear Security Administration Exascale Computing Project