Big Macs vs. The Naked Chef [2001]

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.

"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)

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.

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.

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.

Like using Netscape -> Mozilla as your example of why you should never ever rewrite software from scratch.