There is an old joke among software developers speaking of their craft that failure is not an option — it comes bundled with the software. The punch line refers to the fact that many software projects come up short of the lofty expectations that prompted the work in the first place. Statistics I've seen say more than 30% of all software packages end up performing about half as well as they were expected to. And more than a quarter of them take twice as long to complete as initially planned.
These statistics are worth keeping in mind when the topic turns to software for applications that are supposed to be power efficient. Software developers could be excused if their focus isn't so much on power consumption as it is on just putting together code that works.
Schedule slippage and diminished expectations also explain why if you sit through a presentation on software development tools and you are likely to hear a lot about debugging. Studies show that over 60% of all software development cycles are spent finding and fixing software flaws. The unpredictability of the debugging process is the main reason electronic products hit the market late. It is particularly difficult to fix problems such as complex memory access errors, multi-threading issues, and conflicts among shared resources.
No wonder, then, that makers of development tools put a lot of effort into helping software engineers fix bugs faster and into identifying potential bugs before they happen. Multicore debuggers, static analyzers, and checkers able to review large pieces of code spanning numerous source files are all ideas aimed at alerting designers about potential problem areas.
However, there is one area where software development tools are currently lacking. None of them, as far as I can tell, give software engineers any clue as to which pieces of code lead to high energy consumption or use energy intensive resources.
The typical approach for minimizing energy use on computer chips has been to devise various kinds of stand-by and sleep modes that shut down computer resources that are temporarily unneeded. The concept of energy-efficient software has meant little more than taking advantage of these sleep modes. Apart from how to handle sleep modes, information about coding for less energy use often seems to take the form of tribal knowledge passed along from experienced software designers. In many cases it consists of not much more than trying to minimize memory accesses that are energy intensive. Tools for finding resource-intensive software routines are essentially unheard of.
But as energy consumption becomes more of a front-page issue, there's bound to be more competitive advantage in minimizing power use. So companies looking for the next “big thing” might consider the idea of metrics for the energy efficiency of software itself. Debuggers now show software engineers where to look for bad code; the next generation of these tools could show where code is the most energy intensive.
People who develop software must deal with many issues simultaneously. It's easy to get distracted when working in this kind of environment, so aids that streamline the process while making the end product more energy efficient seem like natural winners.
