The Thimbleberry Inn’s executive chef, Guillaume Portes, was sensational. He took the modest kitchen of this even more modest inn, and using local produce and game, and with a flair for the dramatic, created a menu that drew local, regional and even national attention, in ever widening spirals of epicurean and gastronomic success.
Now, fresh back from a guest appearance on a cable cooking show, Guillaume received a call from a publisher, asking if he would be interested in writing a cookbook: “Everyone loves your food. You’re a genius. If you write a cookbook we could sell millions.”
Guillaume at first was skeptical, “Me, write a cookbook? But I know nothing of writing!”
“Don’t worry,” said the publisher. “I’ll set you up with our best editor, Frank Morris. Frank knows writing. He does all of our celebrity books. It will be a wonderful collaboration.”
A few months later and the cookbook was almost ready to publish. The review copies went out in expectation of rave flap blurbs. But what came back…well…it wasn’t quite what they had expected:
- Complaints that the Inn’s most popular dishes were not included. “Why did you leave out your most popular dish, the Pecan Stuffed Pheasant?”
- Reports that some recipes were missing steps in their instructions, or that the specified ingredient amounts were vague, missing or incorrect. “One spoon of salt? It would help if you were more specific. Tablespoon or teaspoon?”
- Some recipes had ingredients listed that did not seem to be used in the recipe. “What do I use the scallions for? They are listed as ingredients, but nothing explains how or when they are used.”
- Observations that some instruction steps were vague or relied on unusual sources of information. “How are we to interpret a recipe step that says ‘Cook it like Aunt Mable used to cook it’ !”
- Recipes were missing sauces or said simply, “Add your own sauce.” But the Thimbleberry Inn was famous for their sauces. How could any one replicate their dishes if the recipe for their signature thimbleberry sauce was omitted?
- A huge number of typographical errors, broken references, inconsistencies, etc., that showed that the preparation of the cookbook was hasty and lacked sufficient review.
The publisher was confused. The editor was aghast. Guillaume was furious. How could the reviewers do this to us? Back stabbers! How dare they! These dishes are the finest in the country. Everyone who comes to the Inn loves and praises them. Look at the restaurant reviews! Look at my prize medals! Surely the reviewers must be in league with my competitor, the evil Gooseberry Inn, and are merely trying to prevent my book from selling!
The greatest dose of abuse was reserved for those reviewers who reported the greatest number of problems.
As the imprecations grew more passionate, and the volume and temperature rose, a timid voice arose from the back of the room, saying, “Uh, but are they right?”
The room grew silent as Fred Osgood, an old-timer, once editor-in-chief, but now on the verge of retirement, spoke his mind:
I’ve been in this business quite a while, as you all know. I’ve edited cookbooks before, plenty of them. None for a client as big as the Thimbleberry Inn, but the ones I did edit received good reviews and were modest successes in their day.
Frank, I don’t think you’ve ever edited a cookbook in your life, have you? I didn’t think so. The thing you need to know is that cookbooks require careful technical review as well as standard editing. Just because a chef is talented, or a restaurant is popular does not guarantee that the recipes and the cookbook are good. A recipe is not a dish. There is a lot of time and hard work required to turn Guillaume’s natural genius in the kitchen into something that readers of our cookbook can replicate in their own kitchens.
Back when I edited cookbooks, I made sure that we set up a test kitchen and verified every step of every recipe. We cooked, revised, and cooked again until we could say that every recipe worked as written.
I have no doubt that Guillaume can cook every one of these dishes from memory and get it right every time. I don’t think any of us can question that. But that is not the important question. The cookbook is not for Guillaume’s benefit. The question we need to ask is whether our readers can cook these dishes using these recipes. In other words, are the recipes relevant, complete and accurate? This is what makes writing a cookbook different than cooking, and this is where we have failed our readers. The reputation of the Thimbleberry Inn as well as this publishing house depends on us doing this right. We need to send this cookbook back for full and proper technical review.
The room was silent for a minute, as the others gazed at their feet. Then a smirk came over Guillaume’s face and he struck his fist loudly on the table, stood up and said:
But I need this cookbook now! We must do a better job at finding good reviewers. Let’s throw out the reviews we have so far. Let me give you the names of some of my friends, partners and former colleagues. Don’t even bother sending them a review copy. They don’t need to read it. They’ve all eaten at the Inn. They know how good my food is. Just have them fax over their reviews. Let’s get moving, gentlemen! The 2nd edition of the Gooseberry Inn’s cookbook is due out any month now. We can’t be left behind!
Old Fred silently collected his things and left via the back door, muttering.
Insightful analogy! Thank you very much.
–walter
Keep up the good work – I love these metaphorical stories you tell to illustrate *why* OOXML is so awful, and *why* it’s not purely a case of MS-bashing.
You rock.
Excellent, as usual! I love the stories, and they make your points so well. I especially like that you focus on the fact that this can hurt the reputation of both the Thimbleberry Inn and Guillaume, but that neither seems able to see the risk they are taking. I have been trying to point this out to Brian Jones and others at Microsoft for many, many months, but they either don’t want the advice or are overruled by somebody higher up. I am not sure which.
Guillaume Portes is not the only one with a flair for the dramatic! |wink|
I love these pieces. It’s just a shame that, as far as I can tell, Microsoft & ECMA steadfastly refused to incorporate *any* comments into the standard.
The only reason I can think of for this intransigence is that they do not want to touch their source code (which entails high costs.) And this is precisely the point where “The Cookbook” falls short. Documenting the recipes is not enough. Fixing OOXML also means *changing* the recipes.
(E.G., not documenting but getting rid of bitmasks, inconsistencies in data representation, erroneous definitions, file system dependencies, etc.)
Rob – I like the posting, very creative. The analogy here would need to have a group of other chef’s requesting that Guillaume make his recipies significantly more detailed, and to provide samples for all of them to work with, before it ever makes into the editing phase. Your analogy would suggest that only one chef created the cookbook. As I’m sure you are aware, most “cookbooks” come from a single chef and then get commented/changed from other participating chefs. Also, more than a few recipies fail because of too many cooks in the kitchen. :-)
Anyway – again, my compliments on a really creative posting.
Jason Matusow
blogs.msdn.com/jasonmatusow
Rob-
Apt. Excellent!
Jason-
Your point is…?
QE – yes, there is that to consider _as well_, but I think that this story is meant to highlight purely the “do line spacing like Wordperfect 2” or “do kerning like Ami Pro 1” or “do WMF like windows GDI does” parts of the spec. The bits that are mentioned in the spec but never defined.
I think there is one other interesting thing that comes out of the following paragraph:
“Back when I edited cookbooks, I made sure that we set up a test kitchen and verified every step of every recipe. We cooked, revised, and cooked again until we could say that every recipe worked as written.”
No-one, not even Microsoft has implemented the OOXML spec.
By that, I mean that MS has not taken the spec and created an implementation from it. Quite the reverse. They created the implemenetation first, and then generated the spec by simply describing it.
Now, I’ll agree that most standards do this up to a point, in that an initial implementation (or two) is often developed alongside the spec. But almost never does the spec merely describe an implementation and leave it at that. Instead, the spec is discussed, debated and cleaned up, and changes are fed back to the implementation(s). And as these changes are fed back and the implementations are altered to follow it, it becomes more obvious where parts are under-specified, badly-specified or even over-specified.
No-where have I seen a single shred of evidence that any part of OOXML has had this kind of feedback from an actual implementation being written to follow it. MS has merely attempted to described their implementation. Neither they, nor anyone else, has managed to create a full implementation from the spec. And that means that no-one has yes demonstrated that it is *possible* to build an implementation from the spec.
Until that happens, possibly with Mac Office (I think that’s likely to be the first complete implementation) it would seem to me to be pretty hasty to send the spec for standardisation.
Also nice is the post by Jason Matusow in which he discusses Rob’s motivations and his effort in personally producing 83% of alle the US committee’s rcieved comments and also mentions the support for OOOXML by about 1700 organisations.
http://blogs.msdn.com/jasonmatusow/archive/2007/07/18/open-xml-us-v1-committee-vote-and-ibm-motivations.aspx
To adam:
sadly the Mac Office can’t implement the OOXML spec either so they’re simply porting the Windows code across.
There’s various links in the following post:
http://shebanation.com/2007/05/16/ooxml-and-the-mac-more-bad-news-from-microsoft/
1700 organizations support OOXML?! I think you miss the point of my post. Those 1700 organizations never even read the cookbook. They are just commenting on the food at the Inn.
In fact, since there are fewer than 1700 OOXML documents on the entire web (according to a Google search by file type I see only 923 DOCX files) I seriously question whether these 1700 companies are even using OOXML today!
In any case, you’re free to discuss my motivations until you grow blue in the face. But this does not change the fact that OOXML is deeply flawed and should never have been approved by Ecma in this state, and certainly should not be approved by ISO.
As for me producing 83% of the objections, thanks for that info. I must admit that I was not keeping score. But I’d note that almost all of these comments were accepted by the committee, by consensus, including by Microsoft and their allies. Around three others on the committee also submitted comments.
I observe that those who had worked on standards previously and were long-time members of V1 tended to submit comments, while those who joined at the last minute, who lacked such experience, did not. I can’t blame them. It is hard to join at the last minute, try to work within an unfamiliar ISO process and a 6,039 page specification that you haven’t read, and be able to participate fully in the proceedings. Rushing committee members is ultimately as unsuccessful as rushing a standard.
People can claim that these contradictions are nothing more than a stick to beat Microsoft over the head with.
But doesn’t that just raise the question: why did Microsoft give them such a big, pointy stick in the first place?
I mean, they COULD just fix the technical problems with the standard, instead of trying to force-feed it through the ISO.
Last anonymous: the answer is simple. It’s that making these changes is expensive. Microsoft likely does not want to put out the millions that it would cost to remedy the technical flaws in OOXML.
OOXML’s defects are nothing new. They are carryovers from the legacy binary formats and direct transcriptions of the internal representations that Office uses. Many of them are old as the hills. Due to resource contraints (money) they weren not retooled into proper XML. Newer analogues were not available, and rather than cut features (and kill the ability to represent legacy documents), Microsoft simply clothed them in angle brackets and dumped them into OOXML.
Check out the following article:
http://www.joelonsoftware.com/articles/fog0000000014.html
If fixing minor bugs is so pricey, then imagine how much it would cost to, e.g.:
– fully re-implement field codes in Word as XML constructs
– replace the Word VML engine with DrawingML
– adjust all Excel date formulas to delete an erroneous leap year
These would be multi-million dollar projects!
Anonymous > MS gave people that stick because, in the words of Steve Jobs “They just have no taste. They have absolutely no taste. And I don’t mean that in a small way, I mean that in a big way.”
http://en.wikiquote.org/wiki/Steve_Jobs
To Queen Elizabeth.
If costs is th reason for refusing the changes, then it is a short sighted decision. Refusal to change is costing a lot in lobbying effort to get OOXML pass ISO. It is risking their office business by making obvious the technical weakness of Microsoft offering. Is all the grief worth the savings in development costs?
I wonder if refusal to change hasn’t more to do with the time required to implement change? Microsoft need to have a standard now. They need to have a credible alternative to ODF immediately. If they take too long writing OOXML those pesky governments may mandate ODF in the mean time.
I also wonder if refusal to change also has something to do with how brittle the Microsoft Office formats are technically. Compatibility with the installed base my be broken. If that happens, customers may be tempted to say OpenOffice.org is as compatible as Microsoft product with the existing documents.
Mac Office ? Sorry – no independent implementation. The Mac Office group will use port of Windows libraries to import/export OOXML.
Found this on Groklaw: http://www.reedconstructiondata.com/article/CA453654.html
Everyone who votes “yes” without reading the cookbook… well if they “stand to financially benefit from participating in any standards development activity” – they can be sued for anti-competitive activity and can be forced to pay not just for economic damages but also for punitive damages.
Are all these “new members” aware of that ?
What a great story! I don’t even care about the analogy point–I design cookbook software for a living, and I’ve seen some truly bad cookbooks that just didn’t have to be that way.
Reminds me of a post I wrote last week in my own blog:
http://www.cookbookpeople.com/blog/2007/09/08/the-top-3-family-cookbook-mistakes/
I’ll be posting a link to this story today in my blog.