This is why you design the thing, before internal operation. He's working in the wrong mental design language, thinking in terms of how the thing works, rather than how the user interacts.
This was my response as well. The problem doesn't make much sense. Personally I would have made the "mood detector" start button show a progress bar on the UI so that it is obvious that it is doing something, and how long it will take to start the "mood detector". This internal "queue" and "counter" stuff is ridiculous. Just let users press the button, show them a progress indicator and don't let them press the button until the state is changed to fully on/off.
When it comes to third party apps and other things turning the mood detector on and off without the users permission or notification that makes no sense and sounds like a bad idea in the first place. But if it is essential I would make it pop up a confirmation request on the UI so that the user can not only choose whether or not to allow the on/off behavior, but so they will also be aware that the device is going to be turning on or off. Once again while the device is turning on or off show the progress bar.
Perhaps the "mood detector" isn't the most intuitive example. But imagine it's some sort of computer peripheral that several applications make use of. The problem seems simple until multiple agents start to mess with it. So you start out with steve's simple model, and you too will progress to what he ended up with eventually.
on/off seems easy, but it's hard in complex systems. Like how complex can it be to turn windows vista on and off, right?
That is the difference between e.g. Apple and Microsoft. Microsoft keeps adding features so that it can do what a user wants. Apple designs the unit so that it does what the user wants.
I once worked on a project where there was a system with three chips that were expected to be upgradeable (have new versions of their firmware installed).
The problem was that, each of the chips, in its boot sequence, checked that it had the same firmware version as the other chips and died if didn't. Thus no upgrade sequence was possible.
And this problem was discovered close to release.
Bootstrap problems sound ridiculously easy to find "in the design phase" but they are actually quite hard since they depend on overall system properties.
