Sometimes, the policy-makers in businesses don’t think through the full consequences of their policies.  A recent tweet reminded me of one instance that appears to be fairly common, namely the company policy of powering off computers at the end of the day.  If you’re a developer who has to spend time every day recovering from the consequences of this policy, here are some calculations that might allow you to explain it to your company’s management in terms that they understand: money.

For many job types, powering off computers at the end of the day may be appropriate, but for developers who may have reference material opened in Firefox, an IDE with multiple open tabs, maybe a time tracking application, maybe an IM client for collaborating with developers outside the company, it costs time for the computer, the OS, and the apps to be in the same state that they were before the computer was powered off.  As developers are generally expensive, this loss of time can be viewed as a loss of money; you’re effectively paying your developers a higher hourly rate by building inefficiencies into their work process.

It’s understandable that the 16 hours between day end and day start are targeted in the interests of saving electricity, and the cost savings, while small as a percentage of any organization’s expenses, are easy to obtain.  But let’s do some calculations to see if it makes sense to turn off a developer’s computer at the end of the day.

Scenario #0

The baseline, Scenario #0, is 100 developers leaving their computers powered on, but idle, 365 days a year.  This costs electricity, but there is no impact to developer efficiency.  Consider the baseline cost as $baseline, where developers spend $0 of their salaries recovering state.  Any effort to save money will be compared with this state.  Most nontechnical people would assume that any possible solution involving powering off unused equipment would save money, which is why so many nontechnical people advocate the “power off” policy.

Scenario #1

Scenario #1 will test the premise that powering off computers at the end of the work day saves money.  I assume 100 developers shutting down their computers at the end of their work days.  This costs less electricity than the baseline, but there is an impact to developer efficiency.  Developers are assumed to work 250 days a year (50 weeks of work; 2 weeks of vacation; no working weekends).  (I know this will amuse some developers, but the potential cost savings of powering down a computer are directly proportional to the number of days a developer works; if anything, I’m giving the idea a better chance.)  250 work days a year means that computers are unused for 16 hours a day during those 250 days and 24 hours a day during the remaining 115 days, for a total of 6760 hours a year.

The worst-case scenario I could find for average commercial utility cost was $0.1949 per kWhr, and that’s in Hawaii.  So let’s use $0.20 per kWhr as the electricity cost.  In order to know how much money it costs to keep a computer idle and powered on when it’s not used, we need to know how much power a computer draws when idle.  My 3-year-old Core2 Duo laptop draws between 34W and 40W when idle.  Let’s think the worst and imagine a computer that draws 100W when idle, more than doubling my real-world example.  Such a computer would burn 676,000 Watt-hours (or 676 kWhrs) per year during its unused time, costing $135.20 per year for the portion of time in which it’s unused.  If it were powered off during that time, the total savings over 100 developers would be $13,520 per year.  Electricity cost in Scenario #1 would be $baseline – $13,520.

Let’s now consider the time involved.  The best-case scenario for a useful developer may be ~$30,000 per year, though higher is surely more likely (especially in Hawaii).  Let’s also figure that it takes 5 minutes, at best, to restore a powered-off computer to the state it was in before it was powered off.  During our developer’s 250 annual work days, they spend 5 minutes recovering system and software state.  This works out to ~20.83 hours a year.  At $~14.42 per hour, a business could consider that, while they’re not paying a developer anything extra, $300.41 per year of their salary goes toward state recovery.  In a company with 100 identical developers, this means that $30,041 per year is spent paying those 100 developers just to recover from their computers being powered off.  Comparing with the baseline cost, this scenario costs $baseline – $13,520 + $30,041, or $16,521 more than the baseline of leaving the computers on all the time.

The technical among you are already shouting at your screen.  What about suspend/hibernate options?  You can suspend a computer to RAM, meaning you put it in a state where it sips only enough power to listen to a wakeup call while keeping its state alive.  Scenario #2 considers what would happen if computers were put in a low-power state with fast recovery time, and Scenario #3 examines a no-power state with slower recovery time.

Scenario #2

My laptop suspends within 6 seconds, though the time cost does not factor in because I can just close the lid and walk away.  While suspended, it sips 1W of power.  It takes another 6 seconds to wake back up to its pre-suspend state.  Assuming more worst-case scenario math, let’s say that it really takes 12 seconds to recover and sips 2W of power while suspended.  If we re-use the other numbers above, the 100 computers in our fictional company would consume $270.40 in electricity per year when suspended making the electricity cost $baseline –  $13,520 + $270.40, or $13,249.60 less than baseline cost.  Likewise, our fictional company would pay their 100 developers $1200 to wait while their computer recovered state.  This would make scenario #2 cost $12,049.60 less than $baseline.

Scenario #3

My laptop takes 50 seconds to hibernate, though it’s not necessary to wait around for it to finish.  During hibernation, it uses exactly 0W of power to sustain state.  It takes 110 seconds to wake back up to its pre-suspended state.  Let’s make this worse and assume it really takes 5 minutes to recover.  (I won’t increase the power consumption because there never is any in this state; it’s always 0W unless you’re using a laptop and the battery is charging.)  Re-using the other numbers, the 100 computers in our fictional company would consume $0 in electricity per year when hibernating.  Our 100 developers would spend $30,041 of their time to wait for their computers to recover state.  Comparing the cost vs. the baseline, we have an electricity cost of $baseline – $13,520, and we have a developer cost of $30,041, which looks suspiciously like scenario #1 because 5 minutes of waiting for the computer to restore its state is equivalent to 5 minutes of developer time manually restoring its state.

I have simplified somewhat by not taking into account the time a powered-off computer takes to boot, either from a basic shutdown or from a state of hibernation, but if you extend my calculations to include that time, you’ll find that it merely amplifies my results or breaks ties in favor of state preservation.  Likewise, using more realistic values for developer cost and for power consumption amplify the results.

Final Thoughts

It is never a good idea to have developers lose state.  The best-case scenario is to suspend the state to RAM, and if your computers can’t do that, you need to make it happen.

Even with the highest electricity prices and unrealistically low developer salaries, the idea of abandoning computer state at the end of the day to save money does not work.  However, even the best scenarios for saving money, from any angle, are insignificant when considered against a company’s total income and expenses.  So why not just set a policy that improves workflow?

Costs, revisited

Scenario #0: $baseline

All computers left on 365 days a year, 24 hours a day

Developers spend no time saving/restoring state

Scenario #1: $baseline +  $16,521

All computers powered off 16 hours a day during workdays and 24 hours a day during weekends and vacation

Developers spend 5 minutes a day restoring state manually

Scenario #2: $baseline – $12,049.60

All computers suspend state to RAM for 16 hours a day during workdays and 24 hours a day during weekends and vacation

Developers spend 12 seconds a day waiting for state to restore automatically

Scenario #3: $baseline +  $16,521

All computers hibernate, saving state to disk, for 16 hours a day during workdays and 24 hours a day during weekends and vacation

Developers spend 5 minutes a day waiting for the computer to restore state automatically