A recent experience with a hotel coffee machine illustrated one primary difference of philosophy related to software design. It’s a Keurig machine and my wife Sarah was figuring out how to use it to make coffee. She noticed that when she inserted a K-Cup (the little containers of coffee), then the lid for the water reservoir popped open, so that she could fill it with water. At first, that seemed helpful, but immediately, I wondered about being able to open that reservoir even without inserting a K-Cup. As far as we can tell, it can’t be done. Not only that, but since Sarah needed to walk across the hotel room in order to fetch water from the bathroom sink, by the time she returned to the coffee machine to finish the approved Keurig machine workflow, the machine did nothing. She immediately told me that she couldn’t tell the difference between the machine heating up slowly and doing nothing. What had she done incorrectly? We presumed that she had taken “too long” (Why should this matter? Why is there a time limit on making a cup of coffee?) and that the machine needed to start the approved Keurig machine workflow again. This meant turning the machine on (Why?), opening and closing the K-Cup compartment only in order to then close the water reservoir lid only in order to then push the “brew” button. From what I can tell, for no good reason, we needed to run the approved Keurig machine workflow twice in order to compensate for some design element (the machine “timed out”, we guess) that seems to me entirely irrelevant to the task of brewing coffee.
This is a companion discussion topic for the original entry at https://blog.thecodewhisperer.com/permalink/guard-rails-not-prison-bars