How does Software Go GREEN !!!

That's the next question. My theory is that green software uses the least possible amount of reusable (CPU, Network bandwidth, etc)  and non-reusable resources (RAM, ROM, Disk, etc). if one node can do the job of two, we are on our way to achieving our goal in the right direction without impacting other non-functional attributes like performance, scalability, reliability, etc in a negative way.

Lets see some examples in support of this argument from the server side:

1. Usage of Thin-clients & cloud based VMs in enterprise computing saves energy because we save the idle power consumption (200W+) of desktops with a thin client that takes only a few watts. Multicore  and software virtualization has made this happen on the server side. from an architectural perspective, the sum of the power consumed by client, server and network for data exchange must be the least
2. If a space (reusable-resource) bound application needs to handle increased workload, the only ways are to increase the storage (RAM, disk) or optimize the algorithm to improve the space efficiency without impacting performance. This will save an additional node and improve the performance/watt ratio for the application
3. Similarly if a CPU (non-reusable resource) bound application has to handle twice the workload, the only way is to put a CPU with double the compute power (which may not be technically feasible at all) or reduce the CPU usage by 50%. This again saves an additional node improving the performance/watt ratio for the application
4. If we reduce the frequency of disk writes (or we batch the writing through cache), we save power on account of saving frequent disk spin-ups and spin-downs. If we reduce the amount of dynamic data (such as logging, application data), then for every disk we save, we save 10-20W of power consumed. Space efficiency again helps here

The examples for handheld battery powered devices are more obvious (and possibly numerous), since their impact is more visible to the user in terms of improved battery life:

1. If more of screen pixels are black than white or colored (illuminated), then we use less power. Black background on webpages and mobile applications helps. Here screen pixels is the resource
2. Usage of event driven mechanism rather than polling (like blackberry push mail vs. Microsoft ActiveSync simulated push mail) saves power as it uses less CPU cycles and Radio.
3. Limiting the number of background apps (like Windows Phone 8 does) preserves battery life unlike android where there is no such limit, the constraint being only available DRAM
4. Options for email client applications like number of days of email to sync, sync frequency, amount of data to sync (subject, body, attachments) etc saves network bandwidth (radio) and CPU cycles saving power
5. Ability to put the device in standby mode (radios switched off as well as OS hibernated like in Blackberry) during predesignated sleeping hours considerably saves power in always on smartphones
6. Ability to switch off notifications for things like breaking news, when user is not interested saves power
7. Decreasing the resolution of images & videos served to mobile devices saves radio power as well as CPU power
8. Free Smartphone Apps that constantly display advertisements do so at the cost of energy efficiency as they have to constantly poll the server side for advertisements (use of Cellular/Wifi Radio) and then display it if the app is opened (uses pixels). Its a very popular business model, unfortunately its not energy efficient.

So to summarize, I offer (to begin with) that:

Software Design for Energy Efficiency = Software Design for Computing resource efficiency

Computing Resource = Reusable resource | Non-Reusable resource

Reusable Resource = RAM | Disk | Pixels etc  // Done mostly with Data Storage efficiency

Non-Reusable Resource =  CPU | Radio | Network   // Done mostly with algorithm efficiency

The overall objective is to minimize the use of computing resources required to perform a given task(s). Its just a simple doing more(or same) with less (or same) resources argument. Some would just like to equate this principle with Design For Performance.