Waterfall, Baking and Slow Feedback
One of the things that frustrates me the most about baking is the fact I don’t tend to find out whether or not my baking was a success until the very end when I slice into that cake or bite into that cookie.
Even attempts to check out how things are going don’t guarantee good results - you can look in the oven to see if the cookies look like they are the right colour before you take them out, or you can use a fork to check the doneness of a cake or muffin, but these checks are only looking for one aspect of quality - doneness.
You can have a perfectly baked cookie or muffin but it will still taste like shit.
You see, I’ve baked a lot. And I’m pretty good at it (I like to think so at least). But on the way I have failed, several times.
I’ve slaved away in the kitchen, promising my husband that there’s probably (I say probably because I don’t know it’ll be good) something delicious on its way but sometimes I’m only to be met with:
Something barely edible.
My husband then tries to make things better with comments like “It’s not the worst thing you’ve made.”
I then get pissed off for two reasons.
Firstly, all the time and effort - wasted.
But more importantly, it’s almost always too late to do anything about it. I’ve been able to salvage some dry cakes with icing or a glaze but usually I’m just dumping my failed baking into the bin and apologising to my husband for wasting a bunch of ingredients.
The thing is - baking reminds me a lot of the waterfall approach to software development.
Just like with baking, the feedback flow in the waterfall approach is just way too slow.
I haven’t worked on that many waterfall projects (and they were mainly early in my career) but one thing I distinctly remember was how slow the feedback flow was and how costly it was to fix problems if/when you found them because there was such a massive gap between when a problem occurred and when you detect it - let alone be able to fix it.
More Posts on Feedback: