Sustainability: An Impossible Dream?

Sustainability: An Impossible Dream?

By Frances Buontempo

Overload, 30(171):2-3, October 2022

Sustainable development is currently receiving a lot of attention. Frances Buontempo questions what might make this possible.

The UK had a heatwave for four days in August, which happened to coincide with a festival we attended. Lugging kit and sleeping in a tent in the heat was hard work. We did manage to see a few bands, but came back sunburnt and tired. This means I haven’t written an editorial, as ever. We might try to hire a campervan next time. That way, we can keep going, catch up with friends and see some bands, but without exhausting ourselves. In order to keep doing what you love, you sometimes need to find new approaches, otherwise everything becomes unsustainable.

Though the UK does have heat waves from time to time, this one seemed unprecedented. Climate change may well be to blame. Regardless of the cause, when things change, a new approach is usually called for, hence our camper van decision. Sometimes nothing has changed, but you start noticing things have gotten out of hand. It’s all very well saying “DevOps means eat your own dog-food,” but if you get woken up to handle a prod issue every few hours, finding and fixing the root-cause is important. I suspect most programmers will put up with annoyances to a point, and often for far longer than many others would endure, including tedious data manipulation, or sifting through gigantic log files to find errors. Eventually, the tedium causes action. “We aren’t going to take this anymore,” cry the devs. While putting up with the tedium, you can spot repetitive actions that can possibly be automated. This allows you to change the process in order to keep everything the same, at least when looked at from the outside. Keeping a process running usually involves measuring or tinkering in order to keep things ticking over. From the outside, things may appear smooth, unchanging and reliable, but under the calm surface the metaphorical duck may be paddling frantically. Whether this is sustainable or not depends on how much, and how often, tinkering is needed.

Sustainability does not mean keeping everything the same. The UK is having a fuel crisis, with the prices spiraling out of control. Some people are suggesting fracking in order to generate our own gas, the thinking being we would then have a cheaper supply and could carry on as we are. That may not be the best solution for a variety of reasons. Some people are crying out for new ways of heating homes or better insulation instead. Sometimes, we solve the wrong problems. It’s tempting to try to tinker in order to keep things as they are, but sometimes you need a radical change. The same happens with a code base. Sometimes a rewrite is called for. Some style guides include ways to ensure, or at least attempt to ensure, code is maintainable. Adding new parameters to a function, starting with a leading comma springs to mind. It’s easy to forget to add a comma on the line before, and this can cause hard to track down compile errors. Adding

, int yet_another_parameter

to the end of the existing inputs ensures this doesn’t happen. However, adding more and more parameters might be causing another problem. Large and potentially confusing function signatures add to cognitive load. Though such guidelines attempt to help maintain the codebase, they might allow or even encourage the rot to set in. Treating yourself to a whole new function might be better. Anything to make life easier. Well, maybe not anything. Sometimes the open-closed principle is offered as a way to future proof your code, by making it open for extension but closed for modification. Chris Oldwood did a deep dive into the SOLID principles [Oldwood14]. Perhaps making code easy to change is more important than lots of wiring to avoid future changes to existing code.

‘Net zero’ and ‘sustainable’ can be something of a bandwagon companies jump on for marketing purposes, often described as ‘greenwashing’. I recently noticed ‘news’ about a company that had created reusable printer paper. The idea seemed to be that you buy special paper, and possibly ink, along with their printer, which ‘sucks’ the ink off a page and uses it again, for up to about five times. Perhaps this is a good idea, but it will depend on the total energy and resources needed compared to producing paper every time. Finding new ways to do old things is all very well, but that can miss chances for improvement. Whether electric cars will solve the climate emergency, or whether we need to rethink how much transportation and travel is unnecessary, is worth pondering. We can see the same thing happening when we code. It might feel quicker to shoe-horn a small hack in place to get something working, but sometimes that takes far longer than expected, or worse, seems to work but causes hard to diagnose problems later. Do you ever find yourself looking at a function and thinking, “Oh no, not this again.” It could be a badly named variable that confuses you silly, or a very long switch statement. That could make it time for a radical rethink and some rather intrusive refactoring. If net zero means some positive steps are combined with some negative steps, leading to no overall steps that do not seem to be much progress. I have committed code before and been relieved to notice I have deleted as many lines as I have added. The huge spaghetti monster is no worse. Net zero. Perhaps I should challenge myself to make more negative code commits. Let’s aim for better than net zero. Using the climate emergency analogy, a sum of zero is not a sustainable approach, since it fails to make anything better.

We haven’t defined sustainable yet. The word has a sense of keeping going and not dying out, which C++ is managing, despite a period onslaught from other new languages claiming to do so much better. The rival languages do all offer improvements and new perspectives, which C++ sometimes takes onboard. As C++ progresses forwards with each new version, the committee tries to keep backwards compatibility. Bjarne Stroustrup notes:

C++’s C compatibility was a key language design decision rather than a marketing gimmick. Compatibility has been difficult to achieve and maintain, but real benefits to real programmers resulted, and still result today.

He also says, “C++20 is backwards compatible with C++11, that is almost completely backwards compatible with C++98” [Stroustrup21]. The attempt to keep versions compatible includes the application binary interface (ABI), which can make implementing new features surprisingly difficult. Johnathan Wakely talked about this at an ACCU conference, saying “There are lots more things that get done implicitly by the language and so look simple in the code, but…” The rest of the slides explain the ‘but’. [Wakely15]. Compatibility is a challenge. Compatibility is not the same as sustainability, of course; however, it is part of the jigsaw. Trying to keep up to date with C++ changes can be a challenge. Hopefully, some of the Overload articles help and I usually find various talks at the ACCU conference give excellent overviews of new language features. Check out the YouTube channel if you’ve never been to the conference [ACCUConf]. Sustainability means something can continue, whether this means planting new trees for each that gets chopped down, or not using up all your resources, so your program crashes. Sustainability is about avoiding irreparable damage, but measuring anything’s total impact can be difficult, and drawing a line beyond which something becomes irreparable is hard.

Talking about a code base or manufacturing process as sustainable is one thing, but until AI takes over, programs will be created by people, and people get broken too. If you do the same thing for a very long time, you might suffer from burnout. The World Health Organisation (WHO) recognized burnout as an occupational phenomenon, rather than a medical condition, in 2019 [WHO19]. The WHO give this definition:

Burn-out is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed. It is characterized by three dimensions:

  • feelings of energy depletion or exhaustion;
  • increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job;
  • reduced professional efficacy.

Burn-out refers specifically to phenomena in the occupational context and should not be applied to describe experiences in other areas of life.

After my PhD, I couldn’t face reading any more. I managed to nurse myself round by reading The Sandman comics by Neil Gaiman [Gaiman]. If you find you can no longer face doing something you used to love, take a step back. You may not be suffering from burnout, but some ‘me time’ and self-care once in a while is good for you.

If doing the same thing over and over without a break might cause burn-out, doing something familiar can bring joy. I frequently get tasked with writing unit tests for other people after they have written code. I have Opinions, with a capital O, about writing tests after you’ve written code. Test first, people. However, I am happy to add tests to a code base. It can be a good way of finding out how the code works, and it’s impossible to break something vital in production. You might even find out why something goes wrong in prod. I feel comfortable adding tests, because I know how to do this. Some people are surprised that I am willing to do something they think of as tedious, but using a skill you have built up to do something productive is joyful. Bertrand Russell explores happiness in The Conquest of Happiness [Schmitz16]. He says:

Two chief elements make work interesting: first, the exercise of skill, and second, construction. … All skilled work can be pleasurable, provided the skill required is either variable or capable of indefinite improvement. Even more important as a source of happiness is the element of constructiveness.

A sense of purpose and constructiveness might just avoid burnout. He also says:

The most satisfactory purposes are those that lead on indefinitely from one success to another without ever coming to a dead end.

Constant dead ends make tasks unsustainable. Trying to write an editorial, or article, or book may seem beset with dead ends and wrong turns; however, sometimes you find a direction to head in, and the words almost write themselves. Something similar can happen with code; you might find the right data structure and then you’re on a roll. Or a small refactor that opens up infinite new possibilities. In order to find that joy and momentum, you need some agency in the process. Allow me one more quote from Bertrand Russell:

One of the causes of unhappiness among intellectuals in the present day is that they find no opportunity for the independent exercise of their talents, but have to hire themselves out to rich corporations directed by Philistines, who insist upon their producing what they themselves regard as pernicious nonsense.

We mentioned SOLID earlier. We have names for patterns we use when we code. We also have names for things that go wrong. Off by one errors, undefined behaviour, the list goes on. This happens outside of the programming world too. I watched a television programme a while ago called Why buildings collapse. Clearly something of a clickbait title; however, it was very interesting. One phrase stuck in my mind: ‘punching shear failure’. [RISA] This phrase could well be applied to some code I have written. Having a name for your pain helps you discuss it and think it through.

In order to be sustainable, we need to step back and check everything is going ok from time to time. A recent podcast from Stackoverflow [May22] briefly discussed why some organisations are moving AI back from the cloud to on-prem hardware. For a while, it seemed as though everything was going to end up in the cloud; however, people are often seeing huge bills, having got some settings wrong. They are also finding it generally cheaper, even with the right settings, and more performant, than sharing resources in the cloud. Some decisions need revisiting. Have you ever marked a unit test with an ignore attribute, just temporarily, while you fix something? And then forgot to remove the attribute. This may not be the worst form of greenwashing, but let’s avoid ‘pernicious nonsense’ and see if we can make our coding sustainable.


[ACCUConf] ACCU Conference YouTube channel.

[Gaiman] Neil Gaiman, The Sandman, published by DC Comics. See

[May22] Eira May ‘Why AI is having an on-prem moment’, published 23 August 2022 at

[Oldwood14] Chris Oldwood, ‘KISSing SOLID Goodbye’, Overload 122 pages 14–17, available at, published August 2014.

[RISA] Punching Shear – Design, available at

[Schmitz16] Nele Schmitz ‘What we can learn about sustainable development from B. Russell’s The Conquest of Happiness’, posted March 2016 and available from

[Stroustrup21] Bjarne Stroustrup ‘What is the difference between C++98 and C++11 and C++14?’ on, last updated 23 July 2021.

[Wakely15] Jonathan Wakely ‘What is an ABI and why is it so complicated?’ presented at the ACCU conference 2015 and available at:

[WHO19] World Health Organization, ‘Burn-out an “occupational phenomenon”: Internation Classification of Diseases, 28 May 2019, at:

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD technically in Chemical Engineering, but mainly programming and learning about AI and data mining. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.

Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED

By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED

Settings can be changed at any time from the Cookie Policy page.