The importance of making an issue visible
One of the things that's started to help the program energy efficiency
issue on Linux is the development
and popularization of programs like
powertop. For the
first time, people could conveniently get a simple overview of what was
going on with IO and power on their system and, not surprisingly, people
reacted to what they saw.
This provides a handy illustration of the importance of making an issue or a behavior visible to people, both to users and especially to programmers. By and large, if things run well enough (or what people have become habituated to think of as 'well enough') a developer is not going to go to special effort to instrument their program for metrics like wakeup frequency or amount of IO done (it would be a mis-optimization). They may not even be conscious of the issue at all. And when people don't think much about an issue they can't take steps to make things better, even simple obvious steps.
By making the issues visible, these tools both gave developers an easy way to see how their program was doing and worked to make developers aware of the whole issue in the first place. And by making things visible to users too, the tools increased the pressure on developers to get with the program on the whole issue.
(They may also help users make more specific problem reports; there's a lot of difference between 'my laptop battery doesn't last very long any more' and 'powertop says the following three programs are eating lots of battery power'.)
In a sense, this is a corollary of getting the costs right; you can't get the costs right until you can see them (and until you know that they exist at all).
(I'm sure that this is a well-trodden observation. I just feel like writing it down, if only to remind myself about yet another benefit of getting statistics.)