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

The Cathedral and the Bazaar

Or CatB as it is popularly known, is a mecca of thoughts.

A collection of ideas central to tommorrow. Why tommorrow? Ever heard of the third wave? If you have not, we'll postpone detailed discussion for another day. But what it essentially means is that there were two waves of development in the human past; the first wave - when man learnt to grow food. The second wave - when the industrial revolution happenned. And in the same line, todays knowledge revolution is the third wave. And this third wave is changing the fundamentals of our society.

And for me, that is the one and only commandment. Over the days, you will be treated to several of my ideas regarding it. But for now we will stick to Cathedral and the Bazaar. Why am I talking about this? Because, I have several ideas related to this, which i want to discuss.

Cathedral and Bazaar, is a juxtaposition of two means of working, especially with reference to the software industry. The Cathedral is the organized juggarnaut for software production. It is the means employed by the Microsofts, the Oracles and others of this world. Where software is atomized into a set of small, simple tasks, doable by everyone. The Bazaar is the opposite. The unorganized wave of will, driven by motives other than those of profit, moving towards an undefined goal. It is the way the Linuxs of this world are built.

Why am I talking about it?

Well, I found a gem, that for me proves a central point of CatB. Yesterday we had a talk by some seniors who had come from McKinsey. Now these people, working consultants, were talking about the informal and helpful work-culture in McKinsey. The topic of discussion was the effectiveness of the mailing list and how helpful people of McKinsey can be. To quote from memory, "These people are very very helpful. When I was new to the topic, I posted messages, asking about everything and anything, and people responded. They answered all my doubts. And just a few days back, there was a question about which I actually knew something about. So I took that extra half an hour to post a reply. It felt great. That is that work culture here at McKinsey"

That aint no work culture, that is Maslow at work. The satisfaction of having helped. The power of knowledge in the knowledge economy.

The precise idea behind the bazaar in CatB.

The Bazaar is not an accident. Long live the bazaar.
I am Jack's wannabe bazaar

~!nrk