Developers Don't Cook Hamburgers
Metaphors are strong ways of explaining or clarifying difficult concepts. However, the wrong metaphor can weaken one's case.
In his article How finishing what you start makes teams more productive and predictable, Lucas F. Costa uses making hamburgers to illustrate work-in-progress. He's trying to show the importance and efficiency of finishing a task at a time and uses the following illustrations.
Here's the problem. His metaphor is dead wrong.
Let me be clear from the outset. Mr Costa is right about WIP and task switching in software development, and I assume his math equations are right, too. In fact, I encourage you to read the entire piece because it's good stuff.
However, I'm going to argue he shouldn't use the hamburger metaphor at all. It's too easy to poke holes in, and therefore not take seriously. If he tried to "educate the cook" in any of millions of restaurant kitchens on how to cook burgers, he'd rightfully be told he doesn't know what he's talking about.
I've worked as a cook. I do know what I'm talking about.
This point is really important. When trying to persuade people outside our field by using a metaphor, we must know that other subject matter. We can't say, "I know it's not the same, but do you see my point?"
The answer from senior management: "No, because you've made your point using an invalid example. Now I don't trust you. Get back to work on those features and stop complaining."
When you use a bad metaphor, the other person will focus on the flaws in the metaphor, not the strengths of your argument.
If we used this metaphor to try to persuade management or execs who don't understand software development why we should limit work-in-progress, we'd fail. Let's see why.
Computers Cook Hamburgers
How does short order cooking of burgers actually work? (My drawings aren't as good as Mr Costa's!)
Now, what happens if two people order burgers simultaneously?
Why doesn't it take 30 seconds each to assemble and plate the burgers? Because I can combine like tasks. Open both buns, slather both with mustard, place lettuce on both, then tomato on both. Then put the patties on the buns.
Finally, what happens if three customers order burgers one minute apart? Let's make the visual clearer.
Each burger has fixed grill times, with a flip in between. It only takes a couple of seconds to flip a burger.
At the two minute mark, I need to flip the first burger, then start grilling the third. That adds a couple of seconds to the third order.
Similarly, at the four minute mark, I flip the third, then assemble and plate the first.
I then assemble and plate the remaining burgers with almost no pause. My customers each wait about five minutes. This isn't theory; I've done it. If I cook my burgers one after the other, the first customer gets his burger in under five minutes, and the third gets hers in fifteen minutes. She won't be happy, and I'll go out of business.
Why is flipping burgers so different than coding software?
Cooking has significant wait time.
When I put a patty on the grill, I'm not stuck grilling the patty the entire two minutes. The patty is, essentially, grilling itself. I'm just waiting. This means I can start working on something else, and come back to flip the patty when it's ready.
Cooking has lots of async-await. It's highly asynchronous.
In fact, as a cook I can take advantage of my wait times and prepare even more. Assembling a burger involves pre-assembly (buns and condiments), and final assembly (putting the patty on the burger). I can pre-assemble early and plate the burger sooner.
This is very much what a computer CPU is doing. A process is spawned that only uses a portion of memory, and so the CPU spawns another process. It's task switching, but that's what computers are good at, not people.
Does this mean WIP doesn't apply to cooking? No, it does apply. In fact, in a restaurant kitchen, there's a real danger of starting too many orders. This leads to cognitive overload. "Which patties are ready to flip?" It also leads to too many overlapping tasks. "I need to flip these four patties, assemble those five, plate these other two, and get back to these three patties before they burn."
The kitchen, though, has its own WIP limiter: grill space. You can only start so many burgers. This is why you have to wait so long in a crowded diner.
While cooking is highly asynchronous, it is also highly limited. It's a just-in-time system where you only start orders when you have capacity.
But we're still left with a dilemma. We want to explain to upper management why trying to code multiple features at once is severely counter-productive. What metaphor can we use that they'll immediately grasp?
Features Are Books
Software engineering is a creative endeavour. It's not kitchen work, and it's not assembly line work. We need to use a creativity-based metaphor.
If you were tasked to write three books in two years, how would you do it? Would you
- Write page one of each book, then page two, then page three, and so on?
- Write chapter one of each book, then chapter two, etc?
- Write book one, then book two, then book three?
Option one is patently ridiculous. And yet it's how management and developers often think when they're asked to add a new project or feature to an existing workload. "OK, sure, I can fit that in." Or, "Sure, I can do that at the same time."
No. No you can't. This is where Mr Costa's article and math are so helpful, and is the point he's trying to make.
Coding has no wait times. You can't start coding a feature, and then switch to another feature while the first one magically continues coding itself. Coding is highly synchronous.
What are the consequences of trying to write three books asynchronously? Will they be finished sooner, the same, or later than if you write them one after the other?
All three books will be late, and each will take longer to write. Why? Because of task switching. You don't need to be much of a writer to imagine trying to switch between three different books, plots, characters, locations, every page. You'd never read three books that way, right? The reason's the same. The writer needs to become immersed in the story. Switching to another story requires "getting back into it." In software development, this is often called "ramp up time" or "reloading the code into my head" and generally takes ten to twenty minutes after an interruption.
If you want all three books on time, write them one after the other.
There's another important business consideration here, and one that should appeal to all executives. In our metaphor of the writer, I want to finish the first book before starting the second. Why? Because I need the money. That book can get published and I can get royalties while writing my second book. I can also use the reviews of my first book to help improve my next one.
This is critical to understand in software development. We need to work on one feature at a time with minimal distraction so we can finish it more quickly and get feedback to both fix the existing feature and inform future features. We also want to get products to users quickly because that's where the company's revenue comes from.
As the knight reminds in Indiana Jones and the Last Crusade, you must choose wisely. Like all metaphors, the writing metaphor is incomplete. For example, unlike writers finishing a book, programmers are constantly fixing previously released code. Imagine if writers were forced to revise and republish all their books throughout the year! Also, writers do sketch ideas for future books, and they'll edit one book while writing another. But would you have said to J.K. Rowling, "I know we have an August deadline for the next Harry Potter, but we need you to start another book, too, and have it finished in September without missing the August deadline. Plus these five magazine articles."
Of course not.