2010-01-27

Software craftsmanship, and a bread machine

So, I bought myself a bread machine. Yes, I'm a sucker for useful technology, and if something catches my eye as an interesting use of technology, I'm already standing in line. Yes, I'm an early adopter, and with that comes equal amounts of frustration and joy.

In my closet of stuff that just didn't cut it lies the old DCC digital cassette recorders (yes, they were the only affordable digital medium at the time, but that didn't make them any better) , MiniDisc (just waiting for increased internet bandwidth to gobble it up) and my robot vacuum cleaner of which I actually have two, as I just couldn't let go of the idea even as the first one broke down from inhaling too much carpet hair and ... eh, dust.

So, where does the bread machine go? Well, actually it's not a particularly new technology, but rather something that has been around for 20 odd years, but dropped out of fashion during the '90s. Fond memories of waking up to fresh bread when I grew up has resurfaced lately. Surely, bread machines must have improved vastly over the last two decades.

So, setting out to buy my household another machine, I noted with amusement that there seems to be a newfound interest in bread machines, as the household stores now carry them, and most of the bigger (and some less known) brands now proudly display a breadmaker in their lineup.

What struck me first was the fact that they all look like buckets.

Glorified buckets, with a display, but buckets nonetheless. It became apparent that these are not machines that are supposed to be prominently displayed on your kitchen counter (unlike say, the espresso machine, which usually is designed to make all other kitchen utensils fade into the background). Instead, you are supposed to be slightly embarrassed to even own one, and they all come with a practical bucket-like handle so they can be quickly stoved away when not used.

I finally settled for a white bucket from OBH Nordica.

Eager to try it out as I came home, I immediately decided to program it to produce a french bread for breakfast the next day. Adding all the ingredients was simple enough, and then it's just the simple matter of selecting the bread type, size, crust, and finally my breakfast time...

And this is where things went wrong.

Instead of just entering the time as "9:00", I was presented with "3:50" in the display. Checking the manual revealed that this was the total baking time for this type of bread.

"Oh, jolly. It takes you 3 hours 50 to bake a french bread. Good for you. Now, where do I enter my breakfast time?"

Except I couldn't. According to the manual, I have to take the number of hours left to breakfast, subtract the total baking time, and give that number to the machine.

This is where it becomes ridiculous. I can imagine the product owner writing a user story going something like: As a consumer, I want to enter the time I want the bread to be ready, so that I can enjoy freshly baked bread for my breakfast.

The software engineer replies "Can't do it, it's too complicated. Why don't we just let the user punch in the number of minutes left, that way we can just reuse the timer class. Makes the code simpler too, less bugs you know"

Hold on, it gets worse.

At 5 in the morning, I was unexpectedly woken up by a number of adamant, loud, angry beeps from the kitchen. I got up in a hurry, concerned that some kind of error had occurred with the baking process.

It turns out that this is standard procedure. Before starting the second kneading cycle, the machine can alert us if we want to open the hatch (open the pod bay door, Hal) to insert fruit or other late ingredients to the dough.

So, naturally, I looked for the setting to switch it off. And of course, there isn't one.

Incredulously, I checked the FAQ section of the manual. And, there, among a row of queries as asked by the tentative user:

"Question: Can you shut off or lower the noise of the beep signal?"
"Answer: No unfortunately not. The sound level is pre-set and meant to be heard during day time when you have a lot of noises around you."

This rates among the worst excuses I've heard yet. Either a) there was an outcry of users who does not have the kitchen in the west wing separated by sound-proof walls from the bedroom or b) they realized themselves that this was indeed a stupid feature, and had the poor tech writer try to prevent the storm by "explaining" it in the manual.

To be a bit more honest, the proper answer should probably have been:
"Answer: No, because we forgot that user story, since we don't use our own products nor test them in user conditions. " or possibly:
"Answer: No, because our programmers were rushed to write the software in two days after we had let our other engineers perfect the oven/kneader/control design for months"

This might be a silly example to some of you. But it just continue to display the immaturity of software product development compared to other development professions. It is just yet another oh so tiresome example (YAOSTE) of how we bolt software onto the final product as a kludge that must be there, and it is costly too.

And if you don't believe me, it's 2010 now, and we still have new operating systems that are still allowed to surprise you by opening a new window on top of the password dialog you're just typing into. (And if your password contains the letter 'y', let's hope that the dialog that suddenly appeared and disappeared didn't just ask you permission to post all your private pics on to Facebook)

It's 2010! We have to be better at doing these things, and we need to start getting better now! According to Clarke, we're supposed to go to Jupiter with the aid of advanced software, clever software, that will lay out the course for us and plan the trip, without asking us to subtract Jupiter's gravity coefficient from the wanted arrival date manually! Making sure in every way that the mission is not at risk...

...hey... wait a minute....