The tech industry mourned the passing of Sir Clive Sinclair last year. While many mocked the eccentric three-wheeled C5 electric trike at the time, today, it feels faintly prescient. He also brought the world the pocket calculator, though apparently, he was quite the fan of the slide rule himself. But to many, his eponymous Sinclair ZX range of personal computers, starting with the ZX80 in 1980 and the hit ZX Spectrum were the first computers many in his native UK got their hands on. Their first experience coding in BASIC was probably typing in early video games from a magazine. Personally, like many here in the US, I had the Commodore VIC-20, but the experience was much the same. That first ZX80 had just 1k of memory. Heck, the VIC-20 had only 5k RAM, and even its popular successor only had sixty-four.
Still, I remember being entranced by those games and early programs. You had to wring everything you could out of the code to get the software even to run. Frustrating as it was at the time, it enforced a coding discipline that has probably impacted an entire generation of developers. Code had to be tight to work, and an appreciation of elegant code can be found in every DevOps team across the country. Why say in ten lines what you can say in five or even two? Concise code is an art form.
But today, we don’t have those constraints. Working with a computer packing a measly 5k of RAM is laughable. My point is not to marvel at Moore’s law but to highlight the impact it has had on coding. When memory and compute are infinitely scalable with the public cloud, why burn cycles on clean code? Ten lines or two make little difference in applications stretching to hundreds of thousands of lines. In microservices that are so ephemeral, instantiating and collapsing in constant flux, does it matter that the code could have been more concise? Is it worth taking valuable time to refine it if the user experience isn’t impacted? Will anyone notice?
The person paying the AWS bill will, sure. All that extra compute has a financial cost, but even that is ultimately defrayed across potentially thousands of users. Most software isn’t competing on price anyway. So I ask again, is it worth taking the time to write clean code?
Yes! Not because of the UX, or the financial cost, or even some artful sense that software should be coded as elegantly as humanly possible. No, the reason we should write clean code is because of its environmental impact.
Compute equals energy costs
Compute requires electricity for cooling. Anyone who has visited a data center will know they use as much power as a small town. In fact, data centers are estimated to use 2% of the world’s energy. It’s the code running on all those servers, in all those VMs and containers, that is running the processors hot. Bloated code makes them run even hotter. More code, more compute, more cooling, more power, more environmental damage.
There’s plenty of research to point to the environmental impact compute usage has in terms of energy consumption and carbon emissions. The Bitcoin network uses more energy than Switzerland, according to the University of Cambridge. Smash hit ‘Despacito’, the first music video to hit more than 5 billion views, consumed more energy along the way than 40,000 US households do in a year. Even training an AI model can emit as much carbon as five cars do in their entire lifetime. So the impact of software consumption, whether it’s watching a video, trading crypto, crunching data, or even typing away as I am now, is significant.
We’re not going to stop doing those things. For some, even putting their phone down for thirty minutes is a challenge. What we can do as consumers of software is to understand that environmental price. And for those of us who code, we can take the time to write clean code. If not for the sheer beauty of its simplicity, then for the climate.
Beyond the calculators in all the schools, the early generation of video gamers, and even those on their electric scooters, I like to think Sir Clive would be proud if that was part of his legacy. He can keep his slide rule, though.