The demands of modern software development mean programmers are being asked to write more code and deliver new functionality faster than ever before. The adage of “not reinventing the wheel” has given many the shortcuts they need to deliver code quickly and, in most cases, reliably.
Rather than write something from scratch, a software developer is bound to find something suitable in a programming library or source code repository. These days, developers also have the option of drawing on the power encompassed in microservices.
Microservices radically alter the relationship between the software developer and the code required to achieve the desired functionality, as Shaun O’Meara, chief technology officer at Mirantis explains: “In the past, you typically had one developer or a small team of developers that developed every component of the system, each agreeing to work on different components.”
The team had to build everything from scratch, he says, but when software libraries became available, the developer was able to take advantage of pre-built functionality. The big change with microservices is that the mentality of software developers has changed – they are now able to consume work developed by other people and can achieve massive gains in productivity by doing this.
The impact, he says, is that code using microservices tends to consume a greater amount of IT infrastructure than code developed in a more traditional fashion.
The rise of inefficiency in coding
Inefficiency is now commonplace in software development. “Modern tools have made people lazy,” says Andy Powell, chief technology officer at Canterbury Christ Church University. “When I was writing websites – this was before .Net came along, and in classic ASP [active server pages] – you had to write all your own objects.”
When people used to visit websites via a low-bandwidth, dial-up modem connection, he says: “You had to be conscious about the size of the image, stylesheets and page sizes; you had to be conscious about how much data you were sending down the pipe because load time was important.”
For Powell, from an application development perspective, this meant that developers considered code efficiency. “You had to be really efficient with the database layer and your API [application programming interface] layer,” he says.
Queries to transactional systems were written in a way that returned the minimum set of viable data, whereas now, he says: “You get 100,000 records or tuples and away you go, selecting what you want from this [dataset] in-memory because memory has become so cheap.”
Tackling code bloat
Today, developers treat bandwidth almost as an unlimited resource and processing power, and memory and storage are cheap and plentiful. This has led to code bloat, where developers no longer focus on writing software that runs as efficiently as possible and uses the smallest footprint of storage, memory and processing power.
Mav Turner, chief product and strategy officer at Tricentis, points out that code bloat typically stems from several sources, such as overly verbose syntax, redundant or unused features, and lack of optimisation during development. Additionally, he says legacy codebases may accumulate technical debt over time, leading to bloated and convoluted implementations.
However, as Turner explains: “By embracing clean coding practices, modular design principles and regular refactoring, developers can mitigate code bloat and maintain leaner, more manageable codebases.”
IT leaders need to consider factors and drivers that make code developers write less efficiently. “Nobody intends for code to get bloated. Developers aren’t trying to destroy the environment,” says Maurice Kalinowski, product director at Qt.
However, as Kalinowski notes, there are numerous factors that cause unintentional inefficiencies. As an example, he says: “Very often, prototypes end up in a product due to time pressures that force short delivery cycles on development teams. This leads to technical debt later in the development lifecycle, and this, in turn, has the knock-on effect of harming efficiency.”
According to Kalinowski, it is important to consider the application area and use case for the code being developed. “If you’re developing code for ‘general purposes’, does the input data need semantic checking? Does the code cover all potential scenarios, including the ones that may never happen?”
Even highly efficient code may be exposed to additional use cases that need different checking and processing. This, warns Kalinowski, leads to more and more cases where code is written to support these exceptions. As these build up, the code reaches a point where the performance benefits that were originally designed in may well have been lost.
Kalinowski says IT leaders should consider refactoring those parts of the code that are bloated. “Of course, you first need to know which of your projects are bloated in the first place. This is where lots of developer tooling comes into play, like static and dynamic code analysis, profiling and enhanced sampling,” he adds.
Inefficiencies in testing
Tricentis’s Turner urges IT decision-makers to adopt test-driven development (TDD) as a sustainable IT methodology. In his experience, TDD offers a powerful technique that can significantly contribute to the creation of green code, characterised by higher quality and efficiency.
“By emphasising the creation of tests before writing code, TDD ensures that developers have a clear understanding of the expected behaviour and functionality of their code from the outset,” says Turner.
Looking at testing during application development, Ved Sen, head of innovation at TCS UK and Ireland, says IT leaders should also consider the environmental impact of regression testing.
“When you run regression tests, you end up testing a lot of things over and over again, just to see if the program breaks,” he says. “But every time you do a regression test, you’re consuming more resources, and each of these is generating a little bit of a carbon footprint.”
According to Sen, it should be possible to build more intelligent ways of testing, so developers do not have to keep testing the same use case over and over again.
Sen points out that if software developers avoid doing brute force testing, they can reduce the footprint of the IT test and development environment by a small, but significant amount, which cumulatively amounts to a bigger impact on making IT greener and less carbon-intensive.
Beyond coding, IT leaders can also look at addressing the overall environmental impact of the software development and testing environments their developers require.
Speaking at KubeCon + CloudNativeCon in Paris in March, Gualter Barbas Baptista, lead consultant for platform enablement and strategy at Deutsche Bahn, discussed the rail operator’s ongoing efforts to monitor and minimise the ecological impact of its cloud-based applications. Baptista spoke about developer empowerment, describing software developers as “effectively the everyday decision-makers” in terms of what is being put into software.
“If we don’t engage developers and give them the tools, we will not be able to make a change in the way we develop code and the way we manage infrastructure,” he says.
Over the past few years, Deutsche Bahn has focused on converging entire subsidiaries to enforce standardisation. This, he says, means “we can leverage effects and provide a higher level of standardisation”.
Kubernetes is the platform-building tool used at Deutsche Bahn. Monitoring enables IT administrators to see processor utilisation and automatically adjust the container workloads, optimising them to the needs of the workloads.
Scheduling is also being used to help Deutsche Bahn ensure developer and test environments can be put to sleep when developers are not working, which saves processing power.
Greening AI
The IT landscape is constantly evolving, which means IT sustainability is a moving target. In a panel discussion at the KubeCon + CloudNativeCon event, Chuck Dubuque, head of direct product marketing for OpenShift at RedHat, warned that artificial intelligence (AI) is driving Kubernetes to somewhere it has not been before.
“When you add AI to an application, you increase its power usage by 10 times,” he said.
Looking at approaches to making AI greener, Oliver King-Smith, CEO of SmartR AI, says researchers are developing efficient methods of making and using AI, such as model reuse, ReLora, Mixture of Experts (MoE) models, and quantisation.
Discussing model reuse, King-Smith says the technique involves retraining an already trained model for a new purpose, saving time and energy compared to training from scratch. “This approach not only conserves resources, but also often results in better-performing models,” he says. “Both Meta and Mistral have been good about releasing models that can be reused.”
Looking at ReLora and Lora, King-Smith says these are designed to reduce the number of calculations needed when retraining models for new uses. This saves energy and enables the use of smaller, less power-hungry computers. “This means that instead of relying on large, energy-intensive systems like Nvidia’s DGX, a modest graphics card can often suffice for retraining,” he says.
MoE models, such as those recently released by Mistral, have fewer parameters than conventional models. This, says King-Smith, results in fewer calculations and reduces energy consumption. “MoE models only activate the necessary blocks when in use, much like turning off lights in unused rooms, leading to a 65% reduction in energy usage.”
King-Smith describes quantisation as a technique that reduces the size of AI models. “By quantising a model, the number of bits required to represent each parameter is reduced. This shrinks the model size, enabling the use of less powerful and more energy-efficient hardware,” he says.
While quantisation can have a small impact on model accuracy, King-Smith claims that for many practical applications this trade-off is not noticeable.
Tackling code bloat and unnecessary levels of regression testing help to make coding greener. There are also options to use more efficient microservices or algorithms. But the general consensus among industry experts is that it is very hard to change something that software developers have become accustomed to.
Mirantis’s O’Meara sees an opportunity to tackle green IT in software development from the IT infrastructure perspective. “If we can remove the complexity and offer only the IT infrastructure components that are necessary, then we are able to create a thin layer across all IT infrastructure,” he says.
Kubernetes can also be used to ensure the software development and testing environments do not use IT resources unnecessarily.
Such techniques allow IT infrastructure to be lightweight and energy-efficient. A similar technique, as Qt’s Kalinowski points out, can be used in coding to reduce the number of different scenarios leading to exceptions that the code being developed needs to handle.