Mystery: Why is that when I make a huge generalisation, I don't back it up.
You see, consulting is very similar to cooking. I think I read a book about this 'Hackers and Bakers'
...
More seriously, I think this comment sums up this style of article:
'This review captures what's been driving me crazy over the last year... an unbelievable proliferation of anecdotes disguised as science, self-professed experts writing about things they actually know nothing about, and amusing stories disguised as metaphors for how the world works.'
I think the article is SPOT ON. And here's little background about me before I tell you why.
I am from India, graduated in 2001, worked for Infosys for little over 2 years. I have been in US since 2004 and I have been doing independent consulting for 5 years now. I have quite a friends who work for Wipro/Satyam/TCS or IBM/Accenture.
Let me share my experience working with Infosys. I worked on 5 projects for Infosys and all of them were disaster. Infosys hires fresh college graduates, trains them in programming langauges and asks them to do coding for the project. They have processes for everything. Requirements documentation, design documents, the actual code, deployment, you name a task and I can bet that they have a document which tells how you are supposed to do the task. And you can't really divert from the laid out process very much even when you know that the process doesn't make sense. Compound this with the fact that they have many employees who are not really in to technology, so if you suggest an alternate way of doing anything, you will get shot down. [Infosys hires graduates who have no prior Computer Science/Programming experience and some graduates join Infosys because of the brand name and the salary even when they have zero interest in technology.]
Let me give you a concrete example. In 2003/2004, CMM (http://en.wikipedia.org/wiki/Capability_Maturity_Model) was all rage. Infosys was obviously CMM Level 5 compliance company. As part of the certification, every project needs to do analysis of the bug count after every release. So it's like, there were 30 bugs during the first release of the project and 25 bugs during the second release of project which means that bug count went down 16% which is less than 25%, the number required by CMM. So we need to fudge the bug tracker. Unfortunately, you can't delete bugs. So we go back and add dummy bugs for the first release increasing the bug count from 30 to 40 and match up the numbers. I called it bullshit and no one would listen to me. In fact, I was threatned that I will not get good performance review (don't get me started on performance reviews) if I don't follow 'the process'. I left Infosys after 2 years and sweared that I would never join a consulting firm again.
Based on my heated discussions with friends, I can assure that the story is similar at other consulting companies.
I am sure when Infosys was started, it was full of smart people who did the right things and made it into a billion dollar company. But as it got bigger and bigger, the net output is of low quality.
And this validates Joel's main point in the article:
1. Some things need talent to do really well.
2. It's hard to scale talent.
3. One way people try to scale talent is by having the talent create rules for the untalented to follow.
4. The quality of the resulting product is very low.
I started reading Joel in 2003/2004 when I was really frustrated with Infosys and this article hit a home run for me. If you think his analogy doesn't describe the state of big IT consulting companies, I can gurantee that you have never worked at one.
Please. Joel did not write that ALL McDonald workers are idiots. He wrote that McDonald created process that anyone can follow to create a burger which has certain taste. To quote Joel,
"The rules have been carefully designed by reasonably intelligent people (back at McDonald's Hamburger University) so that dumdums can follow them just as well as smart people." (emphasis mine)
Yes, while he didn't say that all McDonald's workers are idiots, you don't write sentences like this if you're saying it's like any other workplace, with it's share of smarties and dumdums, to use his term.
If it's like any other workplace, it's not noteworthy for his essay and he wouldn't have brought it up.
No, I am not. The OP wrote 'continually calling McDonald's workers idiots' and Joel didn't write anywhere in the article that McDonald's workers are idiots.
Maybe I'm paraphrasing or reading too much into it, but this line implies as much
"The other secret of Big Macs is that you can have an IQ that hovers somewhere between "idiot" and "moron" (to use the technical terms) and you'll still be able to produce Big Macs that are exactly as unsurprising as all the other Big Macs in the world."
""The other secret of Big Macs is that you can have an IQ that hovers somewhere between "idiot" and "moron"
He did not say that you must have an IQ of an idiot or moron to work at McDonald. He said that even if you have IQ of an idiot or moron, you can make a Big Mac which tastes like other Big Macs in the world. It's a big difference.
You can read it as many ways and with inflection wherever you like. But even if the insult is indirect, I don't think most would feel better when told they "could" be an idiot as opposed to they "are" one.
For me he could have made a more compelling argument without ever using the terms "dumdum", "idiot" or "moron".
The specific manifestation of the problem may not be novel, but the underlying problem persists. It's the people, process, technology argument. McDonald's is heavy on process and technology but have unskilled labor - as far as restaurant work is concerned.
An article I read in the early 2K's summed up several software engineering studies about the importance of people, process, and technology to software projects. The conclusion, overwhelmingly, was that successful projects had a cohesive team of very good developers. In less successful and completely failed projects, developers were not carefully chosen and time was not allocated to develop a sense of team. Software methodology and technology (equipment, tools, etc.) varied widely and was not deemed as critical to success.
The conclusion was that people were 60% of the success of a project while process and technology were 20% each.
I'll try to find a link to the article. It would have been around 2001 in either IEEE's Computer, CACM, Queue, or Dr. Dobb's.
yeah, really. i'm not a fan of submissions like that aren't at least tagged with the date. sometimes it's not until the fifth paragraph when you read something suspect like 'dotcoms bursting... high-end c++ gui programming.. the hell?' that you realize you're reading a fossile.
I actually like the article but simply wonder if, in the context of 2001, it was not widely believed that organizations like Accenture were incapable of building wonderful software.
Reading this is kind of like reading an article from the 1950's arguing that black people ought to have the same rights as whites. The premise is still valid, but the doubt which justified the article's existence has since been erased.
The takeaway I have is a question. Why isn't there a good equivalent to the big mac in the consulting world?
Every time you go cheap, or with the "big consultants" that joel describes the expected outcome is massive time overruns and massive budget overruns.
The closest thing to the big mac model I can think of is installation of existing software, with customization for the environment, but even there you get the 3 year long SAP projects that cost tons.
What prevents software from being put into a manual? I'm hoping the answer is something beyond "requirements don't match up exactly to previous problems... ever", but I fear that's all it is.
I think there is: the Microsoft product line. They are the company everybody loves to hate for their mediocrity. If you want an office suite, email, calendaring, etc., they are what most of the consultants install.
On the other hand, when you (metaphorically) want the same consultants to go beyond "twoallbeefpattiesspecialsaucelettucecheesepicklesonionsonasesameseedbun", like a McBurger flipper trying to make basil aioli, it usually doesn't turn out well.
Actually, as far as well-specced cookie-cutter stuff, I would say outsourcing/consultants tend to do a good job if they're managed properly.
Where they fail (overrun budget and time) is for more complex stuff. Software complexity requires exponentially better programmers to cope with it. Each time you're building a complex piece of software, it's like you're having to invent the burger again and explain it to a computer.
Couple that with the fact that each company will want their particular meal tailored very specifically to their tastes, so that there's little reuse of recipes possible, and it's obvious why a lot of projects fail when the burger flippers are asked to design a new burger.
Imagine that The Naked Chef gets bored doing "telly" and opens a restaurant.
Like his venture 'Fifteen' that is not only a top restaurant, but also a program for troubled youth? Or more like the half-dozen or so "Jamie's Italian" that have opened?
Or like the dozens of additional "Jamie's Italian" that are planned for Europe and Asia in the next couple years?
Come on, Joel. If you're going to use a metaphor, please make sure it fits... at least a little. Jamie Oliver is already executing on the exact thing you say he can't do; creating a repeatable process to make delicious food and opening a chain of restaurants that sell it.
Spolsky has a talent for using very specific examples in his just-so-stories that then later turn out to be the purest counterexample he could have picked.
Like using Netscape -> Mozilla as your example of why you should never ever rewrite software from scratch.
Mozilla Firefox was forked from the rewritten Mozilla codebase
From the original Spolsky:
> Netscape 6.0 is finally going into its first public beta...Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
You see, consulting is very similar to cooking. I think I read a book about this 'Hackers and Bakers'
...
More seriously, I think this comment sums up this style of article:
'This review captures what's been driving me crazy over the last year... an unbelievable proliferation of anecdotes disguised as science, self-professed experts writing about things they actually know nothing about, and amusing stories disguised as metaphors for how the world works.'