Big Macs vs. The Naked Chef

greenspun.com : LUSENET : Joel on Software : One Thread

I think your usage of the term "Quality" is incorrect and reflects the most common mistake people make understanding quality. McDonalds is NOT low on quality. Producing something exactly to spec again and again and again is what high quality is. Its like saying is the corvette a higher quality car than a honda.... well no! because the number of problems that arise in a corvette is far higher than that in a honda. The spec for the corvette was that of a high performing sports car.... which it fulfills to a degree .... the spec for the honda was to produce an average performance everyday car ... which it fulfills to a very high degree .... thus making it of very high quality.

Regarding your generalisation that all IT consulting firms get greedy and grow faster than they can handle is not entirely true. I worked for a London and New York based company called Quidnunc which took almost 10 years to reach 100 people. And they still insist on high quality AND high caliber (two enirely different terms) work and people.

-- Anonymous, January 21, 2001

Answers

I really do think that before we even get to the discussion about weather McDonalds, Gourmet chefs, or any other IT consulting firm delivers "quality", we have to define this very subjective word. A teacher once told me that one has to define the amount of quality in a product by comparing it against the customers expectations. Every time the product surpasses the customers expectations, it gets "brownie points" on the customers quality scale, and every time the customer is disappointed by a product it looses some of these points. This (of course) makes the term quality very subjective indeed.

Joel says:

"The secret of Big Macs is that they're not very good, but every one is not very good in exactly the same way. If you're willing to live with not-very-goodness, you can have a Big Mac with absolutely no chance of being surprised in the slightest".

So when Joel enters a McDonalds "restaurant" he expects to get decent food for the price he pays, which he argues that he doesn't get (-1 points to McDonalds). Further more he gets this every time he enters a McDonalds everywhere in the world (again -1 points to McDonalds). He then compares McDonalds to any other decent restaurant, where you would expect the chef to improvise just a little bit if the customers complained about the general taste of the food, and because of the way McDonalds is managed they loose another point. McDonalds probably looses another point or two too because now this isn't just a restaurant with less than average food - no - the have a bad management too, which is something that Joel obviously cares about.)

Joels quality experience differs a lot from mine (and probably yours too). When I enter a McDonalds I expect to get very non-exciting food (0 points), I expect to get it fast(1 point), and I hope i tastes just about the same as last time (maybe even two points McDonalds), and I expect a "Meal" to end up with a price tag about $10 every time (Yet another point).

Obviously, my experience of the "quality" at McDonalds is a whole lot better :), all though it's exactly the same company and products.

If you use the same point system with your comparison between a Honda and a Corvette, you will clearly see why the Honda is a superior product -at least with your arguments of expectation.

Think a little about this: If all I really expected from a car was what a Skoda could give me then the quality experience of driving a Ferrari could actually be less than that of the Skoda, because in every way a Ferrari is totally and utterly superior to a Skoda I would probably experience it as bloated with unecessary features.

-- Anonymous, January 21, 2001


What if there is no "spec"? For example, if I have an artist who likes to paint, since there is no spec for what they paint, can I judge quality there? Maybe not. Maybe only against my internal spec.

And it can't just be about expectations, because I expect McDonalds to deliver a subsistence level meal and to have dirty bathrooms, and while they meet those expectations, that's still not a quality experience to me.

So, I can see you have a different definition for quality, which is fine, though not very useful to me to speak with. I think quality exists within the fulfillment of an ideal. If you are fine with the Ideal McDonalds being what it is, you are satisfied with their quality. But if your Ideal meal is far beyond that, than no McDonalds will ever measure up.

This puts quality in the eye of the beholder, which is where I think it belongs.

So, if you want to continue to crank out "to spec" you do that. But unless you have quality specs, which are going to meet MY expectations as your customer, you won't be delivering a quality product.

My two cents. Peter

-- Anonymous, February 26, 2001


I read Joel's article not as a piece about what makes quality software, but as a piece about people. What you or I think of a product, of the level of quality it achieves, is somewhat irrelevant.

The point of the article was that whatever level of quality you achieve with your Methodology, you are stuck there. You have taken people out of the equation and fixed the output of the process at a certain point.

This is hardly a flexible approach to generating a product.

As a couple of other readers pointed out, quality is very subjective. It is affected by the perceptions held by the person interacting with the product. At any time those perceptions could be skewed by some unforeseen force. Burger King comes out with a great recipe for fries (finally), or Sun releases J2EE into the fray, upsetting the application server market. Regardless, if you're relying on a Methodology to produce a rigid product, you need to change the Methodology, and right quick, to adjust to the new market forces.

But if you have a Methodology because you're people are too...'slow'...to take initiative and work outside the bounds of a recipe book, then you're in trouble. They're hardly going to be able to suddenly get creative with their day to day work.

That's the danger of Methodologies - the kind of employee they attract, and the inflexibility of the approach.

-- Anonymous, March 07, 2001


Macdonalds though isn't such a great example of a uniform delivery to experienced user expectation. In different countries Macdonalds actually varies quite a lot, its one of their hidden talents to maintain a global brand and seeming to provide uniformity whilst at the same time tuning that delivery to local taste and habit.

Regardless of the food, if software were delivered the Macdonalds way it would be differently focused for different expectations of localised (not necessarily in language or spelling, but perhaps usage differences) groups of users. There is more than one user model for any piece of software that is even marginally complex.

Sliver (Simon)

-- Anonymous, March 08, 2001


I wanted to respond to Andrew Robinson's comment about the type of people that methodologies attract.

I think your point is that people who are want to work with a stone rulebook that never bends are not the cream of the crop. On the surface I agree, but there's also the other side of the coin; developers who refuse to do anything that will "stifle" them...which in my experience can lead to horrible applications that no one but those first creative souls can figure out. When I hear a developer on my team disparage methodology in general, it makes my blood run cold.

It seems that in order to create cohesive, durable applications as a team, there have to be agreed on standards and methods. Otherwise, we end up with a soup-kettle of cool stuff that can never be integrated or supported by the next batch of developers (after the creative types quit in despair).

I don't want my company to be McDonalds, but I really want to be sure someone checks to make sure the meat is kept in the fridge. A fine distinction, perhaps, but important.

-- Anonymous, April 25, 2001



Fine point, Francie. I actually do agree with you - what I look for in a methodology (lower case 'm' used intentionally) is an approach to building software that displays a level of professionalism. That means taking the time to understand the methods, not so much so you can follow them perfectly, but so you can adjust them and continually improve them. This is a key charactaristic of Extreme Programming and, in terms of flexibility, the Unified Process.

In fact, in the interests of full disclosure, I'm working to bring at least the main components of the Unified Process to my company now. What I do tend to rail against is very strict process that stifles the ability to understand, improve, and truly benefit from methodology.

I guess what I'm really saying is, I hate it when people hide behind Process.

Thanks for you comments - meat in the fridge is a very important consideration!

--Andrew Robinson

-- Anonymous, April 26, 2001


Moderation questions? read the FAQ