Green coding series: Introduction & editorial brief

It’s not easy being green, just ask Kermit.

But thankfully, we’re a long way past the 1970s and the naysayers who laughed at the then Prince Charles (now our course our gracious King) and his mission to highlight the growing ecological challenges that would eventually manifest themselves as ‘global warming’ and the modern notion of climate change and march towards zero emissions.

As physical as so many of the elements in the green movement are, it would seem superficial to suggest that the software and data industry could have any significant impact on the challenges we now face, right?

Well, obviously this is not correct.

We know that cloud datacentres have for a long time focused on Power Usage Effectiveness (PUE) as a metric used to determine energy efficiency. As TechTarget reminds us, PUE is determined by dividing the total amount of power entering a datacenter by the power used to run the IT equipment within it.

Green coding

As important as higher-view PUE analysis is, we must also look down, right down, down to the software application development code and command line.

When we think about green coding we need to analyse all the things developers can do to make their code run as green as possible. In this current series of features the Computer Weekly Developer Network will look to answer questions such as:

What are the common culprits of inefficient code?
How does code get bloated in the first place?
Is a ‘simple’ process of code refactoring the answer?
Should we look for more efficient modern languages (like Python perhaps) to modernise our legacy estates of clunky code?
Why does inefficient code lead to excessive CPU/GPU cycles and storage/networking inefficiency (such as moving data back on and off public clouds) in modern enterprise environments?
How can observability help – especially in the realm of looking for over-provisioned Kubernetes deployments, but elsewhere too?
Does keeping everything in one place (i.e. via use of PaaS and IaaS techniques) make things better from an efficiency perspective?
What measures and grading tools should be used to determine green code ‘cleanliness’ today?
Should this be a self-policing process or an external audited standard be established that code shops have to adhere to?

NOTE: This series is NOT structured as a Q&A based on the above questions, these points are tabled merely to paint the (hopefully green) picture and to illustrate the editorial thread that we wish to pursue here. Other issues might include the following:

Should enterprise IT departments look at getting code refactored into a different language if it’s actually more efficient?
Should be we on the lookout to identify all the bloat that comes from AI-generated code at this still-nascent stage of AI?

A recent analysis showcased on the Computer Weekly Developer Network this year looked at a green coding for Earth initiative. This set of processes looks at cloud cost optimisation functions to find under-utilised machines and helps organisations reduce their carbon footprint.

Datacentre, host, container… code

This work has been carried out with Lloyd’s banking group at the datacentre level, the host and container level… and also at the ‘green coding’ level i.e. work to optimise the source code of applications to reduce the workload placed upon CPUs by making sure it is designed and written in the most efficient software programming language possible.

A long-term initiative from the start (let’s avoid rip and replace), green coding initiatives can be targeted at simply refactoring and optimising one single API, let’s take a zen-like one brick-at-a-time approach.

Wikipedia Image: National Museum of American History, fair use.