Wednesday, October 29, 2003

Communal Source

Everyone knows how currently (2003) Microsoft has billions in the bank. The question most often following that statement is: "If they have all that money why does their software still crash?"

In the corporate world a developer is assigned to create a specific portion of a project. It might be a whole application or just a small module. That portion of code is in owned by one person and rarely modified by anyone else. The original developer may even discourage others from just looking at the code. This attitude is the exact opposite of one of the best feature of pair programming. In pair programming two developers own a piece of code. Code written using pair programming is much more likely to be reviewed and improved by developers other then the original authors. Pair programming creates an enviorment similar to a small scale version of what happens in the open source world. Many eyes look at and improve one piece of code. In the end the code is better, more bug free, and easier to maintain.

Pair programming has been highlighted as a way to produce superior code in numerous studies. In pair programming, two programmers sit side by side on one computer and work on a design and or programming task. While one person is typing the other person can catch mistakes and offer suggestions on how to improve the code. Many times it is as simple as choosing better variable names or adding higher quality comments, but other times it is larger, such as suggesting a design that is twice a fast and half the size. Pair programming is a social activity and also instills the idea that more then one person can improve the code. Having already worked on the code with someone else they are more likely to allow new developers to look at their code and improve it and are less likely to be hostile to those who want to improve it.

At a typical corporation every bit of code is owned by an assigned developer. They wrote it, they release it and they maintain it. A lot of pride goes into their code. They have put in their own standards and might not appriciate others who want to work on their code. Some even take the request to look at the code as an insult. Others don't comment their code as a way of job safety thinking that they will be the only ones that can maintain the code in years to come. Because they don't have or expect anyone else to be looking at their code, commiting code into a revision control system might only occur when their code reaches 1.0 rather then iteratively, which is the purpose of a revision control system. Closed source is rarely viewed by more then one person, missing out on all of the benifits of peer review.

In the open source world it is a common occurance to recieve code fixes and improvments. In turn one doesn't think twice about fixing or improving someone else's code. I have several piece of code that I am responsible for in KDE. The code is kept in KDE's CVS repository and when changes are made to that code I am notified so I can review the changes.

On average the changes to my code are little more then small improvments such as making the code conform to KDE's standards. Other time the changes to the code are new features or bug fixes. More often the changes are in areas where I do not specialize.

No matter what the change is, having your code looked at and worked on by other people is part of what KDE is all about. Browsing through KDE's CVS you wont find a single application that has had only one person touch the code.

The idea that your code might best be served if you don't own it is an idea that pair programing formalized. In the open source world developers had discovered it over time out of necessity. If you want help on your part time project, other developers are bound to touch the code that you are working on, they might even take ownership of it when you get bored. In this philosophy one begins to think of all code as both yours and not yours. You feel an obligation to improve both code that you are working on and improve code that you don't work on. Knowing that others will look at the code you write a higher pride comes into play and the code becomes elegant rather then cryptic.

The reason why Microsoft's applications can still crash no matter how much money they toss at it is because at Microsoft everyone owns their code. A developer only touches the code they maintain. The only person I known to have been fired from Microsoft was a programmer who wasn't willing to fix bugs against his code until "later". The idea that other developers might fix the code would be like telling a stock trader in the 1920's to diversify. Whenever only one developer owns a piece of code it can never be as sound as code owned by many. The collective work will always be superior to the individual.

Popular Posts