My CPOSC 2015 Talk for Android developers.
Category Archives: Programming
How we tell computers what to do.
Supporting Synonyms and Multi-Language Voice Input in Android
My Android Wear app, Resistor Decoder, takes voice input from the user. I wanted to support several ways that users could say the “same” thing while maintaining architectural support for multiple languages. Continue reading Supporting Synonyms and Multi-Language Voice Input in Android
Real-world Automation with Arduino
My CPOSC 2012 talk about automating real-world tasks with Arduino, featuring a garage door opener that knows when you’re home, and a treadmill that knows when you’re on it.
Car Disaster Avoided
As we continue to make software a component of more technologies, software failures are evolving from losing the last 20 minutes of your work to losing the rest of your life. I was recently reminded of something that happened to me years ago, in which I encountered a potentially life-threatening software failure.
In the winter, about 10 years ago, I had a major software failure in my 1997 Saturn SC2. I was living near the top of a steep hill, with a road to match. My drive to work required me to descend this steep road, which hit a low point before rising up again to touch the main road. If you could look at the road from its side, it would resemble a check mark, with my house near the top of the longer stroke. Now picture the road covered with a fresh, wet, slippery snow.
I descended the hill in low gear, to take advantage of engine braking, but I also had my foot on the brake. The action of the ABS brakes caused the usual pulsation in the brake pedal, along with the typical rattling sound, as it kept my speed down. So far, so good. Then, after a few seconds of constant ABS activity, I lost the brakes, as my dashboard lit up with red lights.
“Hmm,” I thought. The low gear was helping to slow me down, but it could only do so much without brakes. My steering still worked, so my plan was to drift down the hill and rely on the braking power of the incline between me and the main road. This was the plan for several seconds, until someone pulled onto the road from an adjacent apartment complex. They were heading to the main road, too, and they were in front of me.
“Hmm,” I thought again. I couldn’t rely on the other car moving fast enough to not be in my way, so I had to come up with a plan B. I quickly thought about the failure, running through various scenarios. While I wasn’t certain, I suspected that I had encountered a software failure, and that the hardware (the brakes and the ABS controller) were fine. Ultimately, I decided to reboot the car.
This was a little scary. Power steering would go away while I did this, even if only for a few seconds. I’d also never started my car while the wheels were in motion. Out of an obscure memory, I pulled information my dad told me once: “You can start a car with automatic transmission in either Park or Neutral.” Park was out of the question, but Neutral would work just fine. So, I turned the key into the Off position, shifted to Neutral, and then turned the car back on. After the usual brief test period for indicator lights, all the red lights were gone. The brakes had resumed their clicking noise, and this time, they kept working. After shifting into low gear, everything was back to where I wanted it to be.
I considered contacting Saturn about this, but I didn’t think it would lead to any improvements. My mindset at the time was that unless I had a way to consistently cause this failure, the report wouldn’t be acted upon. In fact, I only encountered that failure once during the time I owned the car. If it happened to me now, I think I would contact Saturn and anyone else who had an interest in making sure cars are safe to drive.
If there’s any life lesson here, it’s that the Hitchhiker’s Guide to the Galaxy was right: Don’t panic!
Powering Off Computers Can Waste Money
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
Circumventing QA Processes
Now and then, a manager will make a decision to meet a software delivery deadline by bypassing a QA process, because in their mind, meeting the deadline is more important than assuring quality. They may send something broken, but at least they send something broken on time. To be fair, this is not always their fault; their own managers may be the ones enforcing this world view, and adhering to it, however nonsensical, may make a major difference in their annual raise.
Those of us who actually produce work product for a living tend to think of things in terms of whether or not they work, not when they are delivered. The when is largely a measure of how inaccurate the manager’s arbitrary schedule was, nothing more. It took as long as it took to make it work, and that’s that.
I propose that any manager who elects to circumvent a QA process in order to rush software toward a deadline must read and sign a document stating the following:
I’m a manager, and as such, I know way more than the QA department’s trained professionals about the chaotic nature of software changes. I acknowledge that one simple change can cause side-effects that are not obvious, but I’m certain that this isn’t the case here because my mind is more powerful than any mere QA process, and I know better than the entire QA group. If for some reason I’m wrong (which I am not), I will buy everyone a pony of their choosing.
This may seem a little harsh, but when I was starting my career, I became the delivery manager and the QA department, making me the gatekeeper between a deliverable and our customer. I had a total quality failure involving someone who was new to a software module and building it for the first time. Twice in the same week, he assured me it was good to go, and twice in the same week, I trusted that and delivered something that was fundamentally broken. We worked together to resolve the problem, but the lesson I learned was that trust and judgment are not as powerful as a robust QA process. When I elected to bypass the QA process, I was essentially making an implicit declaration like the one above. Of course, I was, in effect, saying that I knew more than me, since I was both the delivery manager and the QA department 🙂
Coding Music
When I have music dominating my ear canals, I seem to be able to slam out code faster and better than usual. I don’t need it to be very loud, but it needs to be loud enough to drown out the ambient noise. I don’t know if the pace of the music makes me want to keep up, or if a lifetime of watching action heroes kick ass to a soundtrack has primed me to kick my program’s ass to my own soundtrack. Regardless, nothing else seems suitable to get me into the zone where I’m a conqueror who uses code like a sword swung from horseback.
Some of my favorite coding music falls into the category of gothic metal or industrial. Some examples: KMFDM, Pig, NIN, After Forever, Nightwish. What about you? Do you use music to get into the zone? If not, what do you do?
Incidentally, this is tangentially related to Nate’s post about mind-enhancing drugs possibly being of benefit.
Programming Injury
No, it’s not carpal tunnel syndrome. I seem to be immune from that because I didn’t learn to type from an idiot.
A couple of days ago, I was actually programming in the same position for so long that I managed to bruise the tissue at the tip of my tailbone. The irony is that I program in a comfy chair which should by no means be capable of such a thing. You really don’t know how often your tailbone is involved in ordinary activities like sitting, leaning, climbing stairs, or sleeping until it’s bruised. Perhaps I need a standing desk to avoid further injury.
Also: How pathetic is it to be injured while programming? On a scale of “twisted ankle trying on new shoes” to “severed nose while bowling” I’d say it’s somewhere around “pulled hamstring while making toast.”