Cooking with Software

No, I'm not referring to software for cooking. I'm referring to an idea for a new metaphor to replace the production line / building analogies: the commercial kitchen.


Kevin is the sous chef at a local restaurant. He calls the staff meeting to order. Before Kevin can begin the business, the restaurant owner comes in and starts to speak, agitatedly.

"I want to change how we work. Starting tomorrow, I want all of the waiters to report to work at 6am. Then, they will contact all of the customers that are coming to our restaurant and get their orders. We'll write all of those up, and then get them to confirm them with a credit card. Then, the kitchen staff will cook all of the meals for the day. When the customers arrive, the waiters will seat them and bring them their meals! Think of how efficient that will make us! Think of how pleased the customers will be when they get their food so quickly! And we'll charge their credit cards sooner and get more money!"

Kevin stares at the owner, and two mini-Kevins pop up, one on each shoulder.

"Kevin! He's insane! How will you predict who's coming? How will you keep the food warm? What if they change their minds? What if..."

The other mini-Kevin interrupts. "Bah! Keep your mouth shut, Kevin, this is your chance to move up... hee hee..."


Kevin's eyes cut left and right quickly, struggling on what to do?

"Uhm, boss, may I say something?" asks Kevin.

"Eh? Yea, sure."

"Well, we're pretty efficient already. We prepare in advance only what we need, and only those ingredients that take a lot of time to prepare, like our sauces. We cut and prepare our bulk so that we can react quickly, but we keep it to a minimum to preserve our workspace and freshness. And, well, our customers get drinks, appetizers, bread, etc., all within a few minutes of being seated.

We don't start cooking their meal until they decide what they want and place an order..."


I submit the modern, well-run commercial kitchen is Lean. Furthermore, it is a better analogy for building software in these, the Aughts.

To document or not to document, that is the question.

What is worthy of committing to storage? Information? Speculation? Knowledge?

I believe that there's a continuum at play here, along the lines of :

{speculation->information->knowledge->...}, where speculation is raw, unverifiable postulates, information is speculation transformed by direct oberservation and/or experience, and knowledge is information so well understood that it has become the currency of wisdom.

So, what's the good agile minded person to do?

Documenting speculation is the basis for heavy-handed methods and is mostly waste.

Documenting knowledge seems a futile activity that seeks to transfer understanding from one mind the the next.

So, is information the answer, dear Occam?

Oh, and for a facinating read from which some of my opinion is based, see Josip Pajk’s article, here.

Beware of hiding requirements as tests

User stories are beautiful things. Details concerning the user story, when expressed as tests, are precious gems adorning the beautiful thing.

But one must take care to not let the tests be a requirement in their own right. Those tests should circumscribe, limit, and clarify the story, just the story, and nothing but the story. If they do more than that then one runs the risk of hidden requirements, and that is evil. Remember, the Principle of Least Astonishment applies to all parties involved in the endeavor.

Edit:  It's 10/13/2011 now.  I've changed my mind.  Tests ARE requirements.  Requirements ARE tests.  They are the same thing.  If a test, especially the Acceptance Criteria alluded to above, describe requirements that would otherwise be missed, Rejoice!

The question is not one of hiding requirements, it is of size.  I've learned that Epic Stories are beautiful ways to manage large amounts of information.  Often the A/C for an epic are stories in their own right.  That isn't something to avoid, it is something to embrace.

The Principle of Denial of Pain, and when to suspend it

The best practitioners I know, both technologists and otherwise, wish to deny customers their pain. In the way that Eric the Phantom of the Opera was driven to make the Music of the Night, these Best Technologist are driven to make virtuous systems, small on pain, for users and fellow technologists. I call this the Principle of Denial of Pain.

But pain is often educational, even medicinal. When we become aware of this phenomenon of our craft, we immediately incur the responsibility of determining when to suspend this Principle for the educating and medicating of our charges.

It is often hard to do, especially if you are in a coaching role. My friend and mentor Ken Howard recently described this same concept like this:

Consulting tip of the week #27: Occasionally you just have to stand by and allow mediocrity to happen -- This can lead to opportunity. (Also see "It's more fun to build a whole house of cards, rather than trying to keep someone else's house of cards from falling.")

So true.

But, you must accept it when you sense it, and you must act upon it when it is time, or you are robbing your charges of valuable, and lasting, lessons.

When do you suspend it? When do you "let the pain flow" for the hope of a valuable and lasting lesson? Well, the times are manifest, but here are some I've personally experienced:

• When you've skillfully made a case for something, but the Team or person is unwilling to accept it nonetheless. Example: Actuals are an important measurement.


• When something is complicated to explain, and in doing so you may get some one's back up (anger, offend). Example: We need to use a tool like Fogbugz to track our defects, because index cards won't work.


• When someone won't accept a Principle for the sake of comfort or a lack of courage. Example: We must provide this feature (support for Leave of Absence) or the customer won't use the system - violated Simplicity- the art of maximizing the work not done.

What are some of yours?

cg