In this, and following episodes of our Green Software Delivery Series, we’ll be walking through each aspect of the Agile SDLC starting with requirements. We’ll propose considerations, actions, and resources that could support green software delivery in each stage. As a familiar and well-trodden pattern, we believe green thinking can be anchored to the Agile SDLC, ensuring care is given to energy use at each stage.

Some of the ideas presented are good software delivery practices with sustainable outcomes. Many of them align with other positive outcomes, such as cost reduction. Where this is the case, you can always add a green lens to ensure you prioritise decisions with sustainability in mind.

Diagram Description automatically generated with medium confidence

Green Software Requirements

Do I really need it?

“There is nothing so useless as doing efficiently that which should not be done at all.”

Peter Drucker

Software bloat is common, especially in the enterprise setting. Oft-quoted Standish Group research claimed that 64% of enterprise software features are rarely (19%) or never (45%) used. Further on, a larger set of data in 2014 estimated that 50% of features are hardly ever used and 80% have low to no value.

While these statistics have been regularly discussed and challenged in Agile circles and have aged a degree, in our experience, they still hold true in many enterprises. There are undoubtedly good practice approaches in modern software delivery that aim to reduce waste, for example, Lean software development. But these aren’t always adopted effectively in the enterprise, and software development regularly leads to bloat and overcomplication.

Given this, perhaps one of the most significant impacts you can make is asking: “Do I really need this? Should I even build it at all?”

Creating more minimal software is a straightforward way to reduce build and operational emissions. Of course, this won’t work if you replace one rejected feature with another; “more minimal software” is the key concept here.

By building more minimal software, you’ll gain many other benefits too. You’ll refactor less, the software will be far easier to operate, cost less, be less complex, and what you create will be easier to observe and further improve the green credentials. You’ll also be able to get the software to your users more quickly.

You can use the additional bandwidth in your team to improve the efficiency of what you have built rather than simply building more. You can even decommission features that you feel are no longer well used.

In an enterprise, this can be incredibly challenging. Many stakeholders have differing views of what is minimally viable in terms of features and non-functional requirements. There will be a range of business stakeholders, user representatives, and teams with non-functional requirements of you; risk, regulatory, security, and more.

It is not uncommon for many requirements to be conveyed as a “must have,” and stakeholders will often overstate non-functionals. You will need to help stakeholders question their perceived needs and demonstrate how a more minimal solution will provide greater benefits with appropriate compromise.

A typical project in enterprise-scale organisations is application modernisation. When modernising or replacing a large, embedded system, it can be challenging to apply the minimalist mindset. The default, usually incorrect position, is often to build a replacement with the same features as the previous one with more on top and switch them over in a “Big Bang” approach.

It’s almost impossible to observe a legacy system’s real-world use. Metrics aren’t always available, and injecting them can be challenging. As a result, the simple assumption is that you need all the features in the replacement. You’ll then end up rebuilding all the previous bloat, significantly impacting the software’s emissions and efficiency.

In this case, it is essential to discover whether what you already have is even the right thing given the needs today and whether incremental replacement patterns are an option, as they can provide an effective way to build, measure, learn, and improve as you go.

 

Non-Functional Requirements And Sustainability As A Non-Functional Need

In the early stages of the software lifecycle, you agree upon and define a product's non-functional requirements (NFRs). Through this process, you make trade-offs between non-functional needs and factors such as cost or complexity.

The same is true of sustainability. Trading-off NFRs, such as response time or availability, will lead to architectures that require fewer resources and, in turn, less energy.

By introducing sustainability into conversations about NFRs from day one, you can enable NFR trade-off discussions and question the service levels driving them.

Commonly, NFRs are greater than the actual needs of an application, and you should encourage discussions that probe and test whether, for example, 99.99% availability is a necessity and upon what assumptions this necessity is based.

An essential aspect of NFR balance is explaining the different solution options that NFRs drive, the potential energy and carbon impact, and the difference in service provided in each option. For example, the difference between pilot light, warm standby, or multi-site active/active disaster recovery approaches and their potential impact on emissions and service recovery time.

For this reason, you should involve an architect with a good understanding of green software development principles in the NFR design process. NFRs are the foundation of software architecture, and their knowledge of solution options will help stakeholders agree on a realistic set of NFRs that can also help reduce energy use.

It is also wise to revisit NFR decisions at key points in the green software development process. Assumptions that led to their initial definition may have changed, as may have your software’s usage. Architects will continue to design new capabilities to meet the NFRs, and if there is reason to loosen them, this can lead to greater efficiency in new developments.

The next in the series will cover design, specifically the architectural decisions that can be made to produce designs that will result in lower carbon intensity.