Monday, October 5, 2009

The Fast Food Chicken Dilemma

One question for you:
What if someone told you that you were going to have to serve chicken less well-done in order to make it through the lunch rush?

Let's say you are working in a fast-food restaurant that is attempting to keep up with Chick-Fil-A and KFC and Brown's Fried Chicken. Speed and quality are important, but you are a fast food drive-up, so the audience is a little forgiving.

Now you find out that the other local drive-up chicken joints are selling more chicken than you are on Sundays. The management suspect the product is not being prepared fast enough. They remind you that quality is important, but sometimes you just have to ship the product if you want to compete, no?

You are only the fry cook. Your manager makes three times as much as you do, drives a much nicer class of car, dresses better, probably has more years of management experience than you have fry cook experience. He probably knows what he's talking about, and he can certainly fire you even if he doesn't.

You know what it means to under-cook chicken. Your steady customers will never forget one bout with food poisoning, and will quit showing up if they feel your food isn't safe. Food safety has legal ramifications. Yet, you have got to keep up in the fried chicken wars if you want to survive in this industry.

Will you cook product ahead of time, and let it sit under the lights? Will you operate a larger number of fryers? Experiment with some new techniques (pressure-cook, then fry)? Would you use smaller portions of chicken? Would you skip the breading stage of the cooking? Increase or decrease the batch size and chicken piece mix? Mess with the heat? Trim a few minutes off the cooking timer and hope for the best?

Knowing that there is a real business problem and that you are only a fry cook, what will you do?

Finally, consider that you're talking about software, not chicken.


  1. Microsoft became what they are today by selling unfinished software. ;-)

    Their current problem is that most of their customers believe that the current version is finished and they are no longer willing to buy the upgrades.

    Seriously however the chicken sandwich analogy has serious defects.

    * People eat three times a day. Many software purchases are one time deals that will not be repeated for many years if ever.

    * You can't send out patches, or upgrades to the chicken sandwich you sold three years ago.

    * You can tell when a chicken sandwich is "done", but no matter how well you test a software package there will always be choices that the development team made which some, or perhaps all customers down the road will regard as a bug.

    (An engineer who I regard as very wise once told me that no computer program is truly complete and finished until the last machine that can run it stops functioning.)

  2. Every analogy is weak, which is why "proof by analogy" is a fallacy, yes? Still, let me give a little support to the valid parts of the analogy.

    It is partly about knowing when the software is "ready enough". We have the spectrum between "disastrously underdone" and "disastrously late". Faced with one disaster, we should not rush into the other.

    In incremental development, we frequently release things that are not fully-featured. In Agile we don't release code that is untested, has never had two sets of eyes, hasn't been demonstrated. Heck, we don't release that kind of crap to our internal testing department (when we have one) let alone a paying customer. This isn't to say the code is perfect, but the *known* defect count is surprisingly low.

    Another valid point is that the technical realities of programming or frying chicken are as real as the business problem, so one can not solve the business issues by shorting the technical issues. To wit: under-cooking the chicken is not an option. Period.

    Another valid point (should be pretty obvious pretty early in brainstorming solutions) is that without some kind of partnership between the people running the business and the people doing the work, little can be done. There are things that the cook can recommend to the management, and management can decide what they can afford and when.

    An insufficient system limits the success of all its participants. Blame and pressure are the marks of an insufficient system.

    A refutation of refutation: Most of the software I use is upgraded frequently, as windows is. I know yours is bundled with a machine that won't be upgraded any time soon, but most of the software I use every day is either a web app (upgraded at will) or has an auto-upgrader somewhere in there. I don't deny the existence of one-time purposes, but I think it's more rare these days and a mostly uninteresting case.

  3. Another simiarity: you can tell when a chicken sandwich is "done", but you can't tell if the customer will *like* it.

  4. Regardless, the real point was that you don't have enough time for cooking it the normal way, and you can't sent it out raw. What kinds of things would you do to have it ready (safely) sooner?