This is an article devoted to the idea that a revolution in software design is needed in order to produce software –or as insiders often refer to it: the code – that is both greener itself and that is designed to help other systems and products become greener… i.e. more energy and resource efficient, less wasteful, more adaptive to current conditions.
There are two often intertwined paths to follow, both of which are important for this discussion. Code itself needs to become greener; using virtual resources more efficiently and thus using fewer hardware resources and less power to accomplish the same computing tasks. Code should also be designed with a feature set that enables other products, running the code, to use less energy and to be able to time shift their energy requirements to off peak periods.
This is the way of the green code.
Two Audiences
The first audience this article addresses is the community of professional software engineers, those who write the code, many of whom, I suspect, intuitively “get “the somewhat playfully title of this article. Software engineers and their front line managers as well have an ethical responsibility to produce code that helps our world become more energy efficient and less polluting and to educate upper management on why this is also important for the business. This means resisting the temptation to ship bloated, processor, and network intensive code that consumes more physical resources than it really needs to either because of engineering laziness or because of often intense pressure from upstairs to ship.
The second audience is the general interested reader who wants to get a peek into the some of the issues surrounding what makes a body of code green or not and why this really does matter in the real world. Sometimes I will delve into rather technical and arcane computer software science issues – this article is about the way of the green code after all, but I will try to keep this as accessible as I can to the wider non engineering audience.
Code is Everywhere
Computer software is pervasive in today’s world most of it running on devices we do no typically think of as computers. Consumer devices such as cell phones, portable digital music or MP3 players, game consuls, televisions, and now most major appliances as well all are running and increasingly are being run by code… by software either embedded into the product itself or installed onto the product.
Everything around us relies on code… from air traffic control, to defense, our cars, our medical systems, to the movies we watch. Even such mundane things as elevators and vending machines are increasingly being smartened by embedding software (and the underlying chips) onto the product. Our factories and the machines that run them are increasingly reliant on software, on industrial robots and computer controlled machines, on just in time ordering systems tied to inventory systems. Huge data centers and networks underlie the Internet, the world’s financial and telecoms systems and the increasingly a lot of other commercial systems.
Code is everywhere in our modern world, but is it green code and does it help promote efficiency and reduce waste and pollution?
Well… What Wrong with the Code?
Software engineers often speak of “code bloat” of software that has ballooned out and that uses an inordinate amount of physical resources such as memory while doing little more –- or little more of the stuff that people actually want — than code that came before it. In technical terms bloated code is space inefficient code.
A lot of software out there is also very inefficient in how it uses other non-memory resources such as the CPU, key sub-systems in the computer architecture such as the graphics sub-system, critical external systems such as databases or the wider network meta-system (so much software is distributed, now a days and relies on networked components that in some senses the network is the computer as John Gage famously pronounced).
Programmers often disconnect themselves – as they work away in their wonderful cathedrals of abstraction –to the reality that memory usage, CPU usage, network usage, database usage and so forth… that all of these things exist as real hardware somewhere, as real hardware that consumes increasingly vast quantities of electric energy in vast data centers or on the many hundreds of millions of machines scattered around the world.
Shoddy software engineering practices have very real consequences, unnecessarily increasing the energy used to provide solutions, the number of physical machines needed, the physical underlying networking infrastructure to support the bandwidth and so on. The kind of code that gets shipped will have a significant impact on whether or not our world transitions into a lean and green economy or falls bloated and unable to adapt to the new realities of scarcity that we are or will soon be facing.
The Beast of Bloat
Often code becomes bloated as patches and fixes are applied to some legacy code base and special case work around code (called shims) or glue layers are added to jimmy one system until it – more or less – fits into and works with another. Another common culprit is copy and paste coding where the engineer – avoids actual engineering – and copies and pastes often large blocks of code in many different places, instead of engineering a proper solution.
Poorly engineered layers of abstraction, indirection and de-coupling often underlie code bloat. When used judiciously, these software engineering techniques are some of the most powerful tools available to programmers, but in the wrong, often sophomoric hands or when a system has been poorly engineered or has been stretched into something it was not originally designed to be, these powerful software engineering concepts can turn a simple task into an overweight, power hungry digital goblin.
Templates… I like templates and use them in my code. Templates are an excellent tool for generic programming… a list is a list, whether it is a list of widgits, thingamabobs or whatchamacallits and templates enable this abstraction. They promote generic code re-use as well as enabling orthogonal aspects – such as say memory management, or life time — to be templatized, in this manner promoting policy based design. Having just sang the praises of templates (or generics in managed code land) I am always aware that template code will expand out (potentially causing bloat in other words) for each type (or templatized parameter policy type) that is introduced. Templates can be deadly like dough nuts and if not used carefully can lead to very rapid weight gain.
Chatty Cathy
A lot of software is inordinately consumptive of network resources – or in code-speak, is chatty – so much software (everything on the web for example) must now operate in a distributed environment, where a client process is remotely connected via a network (which often is the wider internet) to various server processes. Maintaining state and synchronizing behavior amongst these remote components of the software solution is a challenge. However a lot of “solutions” to this problem of maintaining state and synchronizing state across remotely connected processes are overly heavy in their use of network resources, passing too much information that does not need to be sent (and resending it over and over) as well as failing to conserve bandwidth by using judicious abstraction to represent heavier (more bytes) data.
Often the RMI (Remote Method Invocation) client/server stub abstraction layer can induce a kind of delusion in the mind of the programmer that they are making a call into some local API (or Application Programming Interface) and to ignore the reality that there is a whole slew of processes going on, under the hood, from the marshalling of complex types into serialized and often bloated XML based formats (such as WSDL), to the actual routing of the individual network packets sent down the wire and to the reconstitution of the various packets on the receiving node and all the de-serialization that must go on the other end of the pipe.
SOA (or Service Oriented Architecture) and other client/server architectures such as DCOM, RPC, CORBA, Java/RMI and so forth are excellent and powerful paradigms for building software, but they do not come for free and all too often programmers do not fully consider the true costs of these types of solutions when deciding to use them.
In general loose coupling is a good thing, but sometimes things just need to be tightly coupled and trying to shoe horn everything into an SOA design philosophy can lead to network intensive solutions and to real world and very un-green impacts.
Sometimes It Is a Case of Just Plain Stupid or Lazy
Some lazy or ignorant practices are just plain stupid. A classic example of evil code that chews up CPU time slices while doing nothing is the anti-pattern known as busy waiting in which some code cycles through a loop checking over and over again whether some other process it needs a result from has completed so that it can continue its own processing. In this scenario it really is better to sleep (or rather to be put to sleep by the programmer) and wait for an event (a wakeup call if you will). Real world cases of busy waiting are not always immediately apparent; they can be hidden by intermediate code such as by a complex series of function calls. This anti-pattern is not only poor design it is a useless energy hog as well.
Often programmers in managed environments such as Java or .Net get lazy about garbage collection… the garbage collector will take care of it they say. Well sure, but at what cost in the interim? Resources should be explicitly freed as soon as possible even in garbage collected environments. This is especially critical with database connections and other similar scarce resources.
Similarly programmers often ignore the cost of temporary objects, for example in string concatenation using the syntactic sugar of the overloaded ‘+’ operator. It makes it look so simple in the code, but under the hoods a whole slew of temporary objects may in fact be created, objects that consume resources (such as memory, CPU cycles and the garbage collector itself)
Better code through better engineering. Think before pounding out the code. Sleep rather than wait. Never forget that poorly designed code has a real world impact.
What Is Green Code?
Green code is carefully designed to reduce the amount of computing resources required to do the stuff that needs doing, code that simplifies and externalizes rarely used functions reducing overall complexity and code that enables other things being operated by the software to become greener themselves.
By treating computing resources, such as memory, hard drive reads and writes, CPU usage, network bandwidth usage etc as the precious and energy intensive resources that in fact they are green code can make do with less, which translates into less energy consumed in datacenters and by businesses and less hardware to do the same tasks. Code that is aware of its own energy usage and that turns off or sleeps systems that are not actively being used can also have significant beneficial impacts on energy consumption.
By simplifying and externalizing rarely used features into plugin modules for example, code complexity can sometimes be reduced by an order of magnitude and this can result in much leaner, less resource intensive products.
By building green concepts into the design of software systems from the very beginning before any code is even written the resulting software can help drive the adoption of smart energy and water efficient appliances, industrial machines, and building management systems.
Software has a critical role to play in helping the world’s products and services become greener leaner and less polluting and software engineers can take the lead in promoting a green design philosophy in the software sector.
The software industry could really benefit from the equivalent of an Energy Star Rating to award green code and consumers should demand that the software products they consume be rated in this manner. While not a trivial task and no rating system is ever perfect a well designed rating system could help promote the market for green code and penalize the bloat. The recently released Energy Star for Servers specification is a step in this direction although it is geared towards rating server hardware and not software.
