Eureka! Yet Another Way to Screw-Up the Morning Coffee

To understand why I’m so passionate about Loupe you have to first appreciate that writing software is really, really hard.  As Edsgar Dykstra wrote nearly 40 years ago when dinosaurs roamed the earth typing punch cards as even DOS programs and 80×25 VT100 terminals had yet to be invented:  

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility…

Edsger W. Dijkstra, The Humble Programmer  

Yet awaiting Kurzweil’s technological singularity, most computer programs are still written by imperfect human beings like me who can screw-up something as simple as making a pot of coffee.  Case in point…  

Nothing is so simple you can’t mess it up

My wife and I drink our coffee black, so you’d think the only way to screw it up is to forget to add either the water or the coffee beans.  I’ve done both, as well as variants involving too much or too little of either.  I’ve also forgotten both, as when Cindy comes downstairs in the morning asking “Jay, did you make the coffee yet?” Oops!  

You see, when you’re married with kids, you need a division of labor.  In ours, Cindy gets the kids off to school, manages our social calendar, pays the bills, plans the vacations, does the laundry, cooks the meals and does all the shopping.  I program a little.  And make coffee.  Badly.  

We have a semi-fancy Cuisinart coffee maker with a hopper on top for whole beans, a water reservoir and a built-in burr grinder. I mistakenly thought I’d explored the full range of coffee errors sometime ago when I learned that the coffee path between the grinder and the filter basket needs to be cleaned periodically lest backed up grinds prevent beans entry from the hopper. I still forget to clean the mill, but can now distinguish pitch differences in the sound of the grinding that alert me to this oversight.  

This morning the mill was clear, hopper loaded, water reservoir full, filter basket clean and all properly positioned.  I clicked the start button as I dashed to stop our cat from using my stereo speakers as a scratching post and heard the pitch-perfect grinding and water gurgling happily behind me.  Speaker saved, I sat down to enjoy the wafting aroma of French Roast brewing while enjoying a Sudoku.  

Precisely six minutes later, feeling clever at how quickly I’d solved the puzzle, I went to pour two cups of Morning Joe to sip in bed with Cindy as sun and breeze caressed us through the open bedroom window on this glorious Sunday morning in those precious quiet moments before our two boys awoke with breaking news of massive school projects and major tests due tomorrow.  

Our morning coffee was particularly fragrant, benefiting from an unprecedented abundance of surface area.  Coffee was pooled all over the counter and the floor – behind the stove, under the vitamins, and coating the bottoms of the cups and plates waiting patiently beside the sink in the aftermath of last night’s birthday party for my father.  

Mocking me from the counter (rather than below the filter basket where it belongs) was the empty coffee carafe.  

So, what’s this have to do with software engineering?

I suppose I could apply Scrum to my coffee making, but there’s not always someone around to collaborate in Paired Brewing.  Or maybe introduce a stage-gate Coffee Preparedness Review in a quest for ISO-9000 certifiable Brewing Process Maturity.  Or maybe use value stream mapping to achieve Lean Brewing.  I think my best bet is to pause for a moment’s contemplation before pressing the start button on how I suck at making coffee as I double-check that all is ready to go.  

Likewise, in software development, the humble programmer should build defense-in-depth against human fallibility.  Pick a methodology that works for you and stick with it.  Get feedback early and often.  Introduce as much automated testing and quality assurance as you can.  And close the loop in your software development process by measuring how your apps perform in the field so you can be more responsive in the short-term and continuously improving in the long-term.  

We wrote Gibraltar because we’re passionate about rock-solid software.  Like any asymptotic goal, the destination is ultimately impossible, but you can get closer and closer.  The journey is the fun part.  Gibraltar isn’t perfect either, but it’s very good and getting better and better.  Try it and see if we can help you move faster and have more fun on your software engineering journey.  

Join the conversation!

Have a similar story to share?  As professionals entrusted to create rock-solid software, what are we to about accomodating our unlimited human potential for error?  What are your thoughts?  

Let’s continue the discussion in the comments.