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.