High performance and sustainability correlate; making software go faster by improving the efficiency of algorithms can reduce energy requirements, Holly Cummins said at QCon London. She suggested switching systems off when not in use to reduce the environmental footprint. Developers can achieve more by doing less, improving productivity, she said.
A high performance sustainable system should have a low memory footprint, high throughput, avoid excessive networking, and support elastic scaling. These are characteristics we already want for our software, Cummins said.
Building hardware has an environmental impact, both in terms of raw materials, and embodied carbon from the energy required, Cummins said. When the hardware reaches the end of its life, it ends up in landfills. E-waste, or electronic waste, takes up space, and puts non-renewable resources like copper, platinum, and cobalt out of circulation.
E-waste can pose health hazards to the people doing the recycling, so the best way to solve the problem is to just generate less of it, Cummins suggested.
Often, software has obsolete assumptions baked into its design. If we can identify those assumptions and update the design, we can improve performance, reduce latency, reduce costs, and save energy, Cummins explained:
Many Java frameworks make heavy use of reflection, which allows the behaviour to be updated dynamically. But for modern applications, that dynamism requirement isn’t there anymore. We don’t swap out application components at deploy-time or run-time. Applications are often deployed in containers, or the complete deployment package is generated by a CI/CD run.
To reduce the environmental footprint, Cummins suggested switching systems off when they’re not in use. Many organisations will run a batch job at the weekends, but keep the system doing the job up all week. Or they’ll keep staging systems running overnight, when no one is using them:
People are nervous about doing this because we’ve been burned in the past by systems that never behaved correctly again after being turned off. This fear of turning things off is kind of unique to computer systems. Nobody goes out of a room leaving the light on because it’s too risky and complicated to turn the light back on.
Boilerplate code- code that’s pretty much the same in every application- is a sign that the API design, or maybe even the language design, isn’t quite right. It’s a waste of time for developers to write code that isn’t really adding differentiated meaning, Cummins explained:
The solution to boilerplate is not to get AI to write the boilerplate; the solution is to design more expressive APIs.
Cummins mentioned that there’s evidence that we can achieve more per working hour if we work less, and achieve more overall:
Henry Ford moved his factories from a 48-hour, six-day working week to a 40-hour, five-day working week, after his research showed that the longer hours did not result in more output. More recently, a study found that companies experimenting with four-day weeks report 42% less attrition, which makes sense, and a 36% increase in revenue, which is perhaps more surprising.
At an individual level, studies find that switching off can improve productivity, Cummins said. One mechanism for this is the default mode network, an area of the brain that becomes more active when we’re not doing anything. The default mode network is involved in problem solving and creativity, which is why so many of us have great ideas in the shower, she said.
Cummins mentioned Jevon’s paradox, which says that increasing capacity increases demand. This is why widening highways doesn’t reduce travel times – more cars use the new, wider, road, and so traffic jams still happen. We can take advantage by leveraging an inverse Jevon’s manoeuvre. If we work shorter hours, the demands on our time become lower, and we can still achieve important things, she concluded.
InfoQ interviewed Holly Cummins about eliminating software waste and reducing the environmental footprint.
InfoQ: How can we eliminate software waste?
Holly Cummins: Dynamism has a cost; many Java applications are paying the dynamism tax, without getting a benefit. Quarkus fixes this by providing a framework which allows libraries to do more up-front, at build time. That shift to build time gives applications which have a smaller memory footprint, and run much faster.
Also, smaller, fine-tuned, generative AI models can sometimes give better results than big models, for a lower cost, and with lower latency. Or for more complex problems, linking a few smaller models together with an orchestration model can work great. It’s challenging the assumption that bigger is always better.
InfoQ: How can we build systems with a smaller environmental footprint?
Cummins: We should design systems to have a light-switch-like ease of turning them on and off. That means idempotency, resiliency, and infrastructure as code. That’s more or less what you need anyway if you’re designing cloud native systems. Once the systems support it, we can automate turning systems off when they’re not needed. I call the two of these together LightSwitchOps.
Just turning things off can generate pretty huge savings. For example, a Belgian school saved €12,000 a year with a script to shut computers off overnight, and a US company reduced their AWS bill by 30% by stopping instances out of working hours. Scripts don’t need to be home-rolled, either. For a more interactive solution, Daily Clean gives a nice UI for setting power schedules.
