Green coding - Qt: What’s bloating your code?

This is a guest post for the Computer Weekly Developer Network written in full by Maurice Kalinowski, product director at Qt – the company is known for its cross-platform application and UI framework for developers using C++ or QML.

Kalinowski writes in full as follows…

When it comes to carbon emissions, we think of things like fossil fuels, agriculture, or deforestation. But do we think enough about how our code inefficiencies in software contributes to those carbon emissions

More to the point, do enterprises fundamentally understand the software development processes that lead to these inefficiencies in the first place? Creating efficient software and products should be a top priority, but we might need to install an update to “patch” the misunderstandings that sometimes take place.

Where are the inefficiencies?

Nobody intends for code to get bloated. Developers aren’t trying to destroy the environment. There are, however, factors that cause unintentional inefficiencies. Very often, prototypes end up in a product due to time pressures that force short delivery cycles upon development teams. This leads to technical debt later in the development lifecycle and this in turn has the knock-on effect of harming efficiency.

First things first, you need to ask yourself, to whom is the code inefficient? 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? Etc. etc. While the idea of breaking down and modularising parts of your software product may sound attractive, the danger is that you lose context.

Sources of excess

There are many reasons code can become bloated. Even highly efficient code could get exposed to additional use cases the need different checking, processing, etc. This leads to more and more edge cases, up until you reach a point where the initial performance benefits you enjoyed have now been lost.

Maurice Kalinowski, product director at Qt.

That is why it can be helpful to consider refactoring those parts of the code. Of course, you first need to know which of your project 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 – these are just a couple of methodologies that can help.

Now, code refactoring is useful for the purposes of efficiency, but only to a certain point. Usually, the purpose of refactoring is to enhance a certain aspect of your code, like the way it interacts with other parts of your architecture. Yet, it’s not always 100 percent evident how certain code is being used – especially for frameworks where one might quickly realize that the code there is being used in a very different way than what was originally intended. In other words, one might lose sight of the holistic picture.

Sustainable software languages

As a rule of thumb, there is no such thing as a perfect programming language – no one language to rule them all. Having said that, spend enough time with programming languages and you will quickly identify that the ‘easiest to learn’ languages might actually run contrary to your goals of efficient or sustainable code.

Python is a good example of this. The tradeoff for it being accessible is performance, which in turn leads to energy waste. Coincidentally, this is also one of the many reasons why many Python libraries used for modern trends like Machine Learning utilise libraries from other languages like C++.

Agree on methods

We could go on about other things that contribute to inefficient code. Quality assurance has an impact, too. The rise in the amount of software testing being done – particularly the rise of CI/CD leading to whole test suites being tested on all aspects of a software architecture for every minute change – is causing quite some energy mis-utilisation as well. Given that fact, how do you identify which tests need to be run for a specific code change?

How can you optimise your testing infrastructure against criteria like energy usage, efficiency and performance, while still providing test coverage?

These are things to think about.

Holistic efficient

Fundamentally, though, everyone needs to agree on the same tools, certifications and measurements strategies to compare different solutions against each other. Then, we have to acknowledge that, yes, a holistic analysis of software architectures, especially for energy efficiency, is very hard to achieve.

Some markets have settled on approaches to mitigate this. In Germany, for example, there’s the “Blauer Engel” certification (Blue Angel) – where as a vendor, you have the chance to get your software certified.

These initiatives are just at the start of their journey. The more awareness sustainability and energy efficiency gets, the more we will see these kinds of programs, leading to better, more fine-grained development tools. Only then will we be able to make sustainability a fundamental pillar of the software development process.