CATB Revisited

This is in continuation of an earlier post, where I talked about the Cathedral And The Bazaar (CATB), which I believe is one of the most powerful essays of its kind. In this post I want to talk about an experience which makes the Bazaar a more meaningful idea.

Okay the basics first. The CATB talks about two forms of software development - the cathedral or the proprietary model (the Microsofts of this world) and the bazaar or the open source and related models (the people behind GNU and Linux etc). In comparing the two models there have been sevaral ideas thrown in, economic, psychological etc. Here is another insight.

Was talking to a friend yesterday, who had worked in an Infotech company called Infosys. During the discussion we almost immeadiately agreed that she was not a person who hated technology, until she joined Infosys. Something happenned at Infosys that forever changed her opinion about technology. This somehow brought on deja vu for me. I remembered having the same discussion with more than one person earlier. Suddenly it struck me, that the reason why ex-Infocions were shying away from technology could actually lie with their stay in Infosys, and might not be a coincidence after all. I decided to find out more.

It seems that Infosys, during the days of boom, used to the hilt its USP of cheap Indian workforce. Infosys, periodically hired some of the best talent in the country by throwiing enormous amounts money at them. In fact, Infosys became such a phenomena that any engineer, irrespective of discipline, wanted to end up doing a job with Infosys. So much so that there actually were fears that there would be a resouce crunch in other engineernig disciplines in the country if Infosys continued on its path. Fortunately, the bubble burst, but that is another story.

Now all these engineers, intelligent people mind you, who were 'bought' by Infosys were taken to their imposing zoos and housed in A/C cubicles and were given crap as work. Infosys followed standard "cathedral" models of software development. Small groups were given specific tasks. Each individual was further given smaller, meaningless, 'coglike' projects. It primarily consisted either of repititive 'copy paste' of existing code, or testing and recommending changes to other code authors. Work was always in small modules.

There was no real development - no one developed a sensible module, everyone attacked a small very very focussed I/O situation. There was hence no learning, either of the programming language or the logic of the problem or hints of the solution. Further, due to reasonable code archives, development was little other than copy-paste. It generally ended up as dreary repititive work, but someone had to do it, and someone human. Not only was there no learning, but the reward for doing something well was repitition of the same job - over and over again. In the name of specialisation, absolutely no job rotation was possible, atleast not enough to retain interest. And about having ownership of written code - hah forget it.

One another class of operations was testing and bug-fixing. The testing section was another nightmare. Testing, is something not generally relished by builders of code themselves. Imagine having to test code that has been _assembled_ by another person. Sheer boredom - no quality work was possible. Still more stagnation in the entire process.

Bug-fixing was worse. Yeah it was. Bug-fixing naturally involved more than one person, the testor and the actual developer. And relations between the twain always managed to deteriorate. This meant that bug-testing was never with a view to improve code, or performance, but just to impress/escape observation of peers. All the wrong reasons, for the most critical of operations.

And this is a typical model of software development. So what did this result in?

First of all, it made the people involved _hate_ code. And not just code, the hatred extended to just about any technical issue. Considering that most of these people were engineers from established institutes, such hatred was no mean feat.

Secondly, the sheer monotonicity of the jobs resulted in a very high turnover of jobs in the organization. The high pays helped, but not for long, and not in the current environments. And not to mention, this did not help the quality of code in any positive way.

Third, the code suffered, and the costs sky rocketed. Some of the prices that Infosys quotes, almost makes me jump out of my skin. And this is just not restricted to Infosys alone. Ever looked at the prices of software? If you are a developer, you will know how high they *really* are. Have you ever looked at the quality/functionality of most software and wondered why it cost so much. Well here is the reason for you. Incredibly costly man-hours. And the model is to blame.

The best part of course, is that I have not even touched the great sink called maintenance, and services. That is another story for another day. But looking at the basic development model alone, doesnt it not look so incredibly inefficient. Compare this with a plausible model using open source components, and a bazaar style of development. Can the Cathedral ever match the prices of the Bazaar?

No, never. Once the customers realise that, the Cathedral will find survival difficult.

signing off as in the last post - Long live the bazaar.

~!nrk