Confession? I don't write green code. I mean, it might be green code just by coincidence, but I've never really thought too much about the relative energy consumption demanded by this design pattern or algorithm versus some other. Sadly, this is true even when I'm working with actual hardware and low-level software, such as that written in plain C for embedded devices (in my case, for an Arduino board or other microcontroller platform). What's more, I don't think the green code idea has ever come up in my years of computer science classes.
I'm hardly the exception, according to a paper presented this week at the 38th International Conference on Software Engineering. In interviews and surveys conducted with 464 software engineers from a range of disciplines—including mobile, data center, embedded, and traditional software development—researchers found that where green coding most matters, its practice is rare.
"Despite its increasing popularity as a research topic, little is known about practitioners' perspectives on green software engineering," the paper notes. "Even basic questions such as 'What types of software commonly have requirements about energy usage?', 'How does the importance of reducing energy usage compare to other requirements?', and 'How do developers find and correct energy usage issues?' do not have clear answers."
Green software development is as it sounds. In their own words, the researchers behind the new paper, a team drawn from IBM, Google, Microsoft, and the University of Delaware, were looking specifically for answers relating to how software engineers think about battery life/energy usage when they write requirements, design, construct, test, and maintain their software.
The researchers presumed that, of the different flavors of developer surveyed, those writing software relating to mobile devices, data centers, and embedded systems would be most likely to use green practices. These are, after all, the domains where energy use is most critical.
"Based on our interviews, we initially theorized that practitioners with experience in mobile ('battery life is very important, especially in mobile devices'), data center ('any watt that we can save is either a watt we don't have to pay for, or it's a watt that we can send to another server'), and embedded ('maximum power usage is limited so energy has a big influence on not only hardware but also software') would more often have requirements or goals about energy usage than traditional practitioners ('we always have access to power, so energy isn't the highest priority')."
This turned out to be accurate for only mobile developers, who used green practices more than any other group, with 53 percent reporting that they "almost always" or "often" wrote applications with energy usage requirements. For embedded and data center developers, 75 percent and 86 percent of those surveyed rarely or never programmed according to energy usage requirements, respectively.
As to why this is, the researchers were able to get some insight from more qualitative interviews with study participants. The reasons given aren't actually all that surprising. In the words of one data center program manager:
Our main concern is marketshare and that means user experience is a priority. We can be more efficient to try to cut costs, but since we don't charge by energy used this doesn't make us more attractive to users. So we tend to focus on other things like performance or reliability.
Embedded systems developers, meanwhile, offered several reasons for disregarding energy usage. One of these is that, while embedded systems usually involve programming at hardware levels, the systems involved very often have access to non-battery power. Another reason given was that developers often rely on hardware and not software to provide energy efficiency. And finally: "Ensuring the deterministic, real-time behaviour of our embedded device is more important than saving energy."
The paper has several suggestions as to how to generally improve this not-so-green development climate. One example comes in the subfield of software testing and debugging, where developers would like tools that can help detect energy issues and to determine if the amount of energy being consumed to complete a process is reasonable for the amount of work being done.
Generally, the developers interviewed were at least interested in green engineering practices and said they would use whatever help they're offered (debugging tools, example code, documentation, etc.). So, it's less a situation of willful neglect than it is relying on business-as-usual defaults, which is fortunately something a whole lot easier to correct.