oreilly.comSafari Books Online.Conferences.


What Corporate Projects Should Learn from Open Source
Pages: 1, 2, 3, 4, 5

A good senior executive or manager should approach a software project in exactly this way. Yet in a corporate environment, it's rare to find such a person. Instead, the corporate environment seems to breed an attitude of infallibility. This may simply be because a senior person is paid more, and he feels that he needs to justify his salary. Or he may simply believe that the mere fact that he is paid more and is higher up in the organization's hierarchy means that any lower-paid subordinate who disagrees with him is automatically wrong. ("The boss is always right!")

That's not to say that there are not good corporate projects, or that there are no good senior managers and executives. There certainly are, and those people do trust their teams. When team members have ideas, the manager listens; when the manager disagrees with a team member, he argues it on the merits of the idea, and doesn't simply pull rank. (And, more often than not, he loses the argument gracefully.)

But the corporate environment seems to be set up to pathologically encourage this problem, and to breed distrust of the team among senior managers. For a leader--whether an executive, middle manager, or project lead--to do a good job in a corporate environment, she must be aware of this shortcoming and actively work against it. If she follows the "benevolent dictator" model adopted by many open source projects, that's exactly what will happen.

Review Everything, Test Everything

Open source projects have a long history of embracing the idea of reviews. As Eric Raymond points out in The Cathedral and the Bazaar (O'Reilly 2001), "Given enough eyeballs, all bugs are shallow." He calls this "Linus's Law" (in reference to Linux creator and maintainer Linus Torvalds):

My original formulation was that every problem "will be transparent to somebody." Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. "Somebody finds the problem," he says, "and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge." That correction is important. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.

This is an excellent description of why reviews are important, and why they work so well to remove defects from software. Yet in many corporate projects, it is nearly impossible to get the time to perform reviews. Vision and scope documents--a short description of who needs the software, what the needs are, and how the project will meet those needs--are never distributed, read, or commented upon. (Often, they're not even written, and the team is never given a chance to understand or influence the scope or purpose of the project that they're working on!) Database designs, class models, and other technical documents are not inspected for mistakes or defects. And most importantly, code is committed to the source control repository without ever having been code-reviewed.

These important activities are all avoided because a manager arbitrarily decides it's inefficient to do reviews. Yet study after study (and, more importantly, the direct experience of many developers) contradicts this. It really is true that "more eyeballs" leads to better software.

So why do corporate project teams and managers see reviews as "bureaucratic," while open source projects see them as vital? There's a simple explanation: people have a natural tendency to avoid seeing their work criticized. It is rare for most professionals outside of a software engineering team to place their work under a microscope. And what's more, when a person's livelihood is attached to his work, then he may not want his "mistakes" to be shown off to the rest of the team. In essence, many people intuitively feel that reviews amount to a wholesale admission that team members got paid to make mistakes. And that just doesn't sit well with a lot of people.

But that's not enough to explain the intense animosity towards reviews that exists on many corporate teams. After all, everyone does make mistakes; catching mistakes early and building a better product is clearly the most effective way to protect everyone's professional reputation. So why the resistance?

It may simply be that the standard of quality in open source projects is higher than that of corporate projects. Many corporate teams are pressured by their senior managers to build the lowest quality software that they can get away with without losing customers. There is seemingly sound business reasoning behind building only what's necessary. This reasoning holds that what's best for corporate profits is to ship the cheapest software possible. Many corporate managers interpret this to mean building the lowest quality software that customers will still buy, even if that means shipping it with multiple and severe known defects. (Of course, that reasoning often makes sense only in the short run; eventually a reputation for building poor software can sink a company!) But even if this were always true, it would be a poor argument for eliminating reviews, because it's much cheaper to find and repair defects early on in the project than it is to build them into the software, only to have to dig them out much later. While this is a false argument, it's a highly influential one; as a result, corporate teams routinely ship poor quality software that has not been reviewed.

This is the polar opposite of the attitude of open source projects. On a well-run open source project, code is carefully reviewed and accepted before it is committed to the version control system. Project contributors feel that it's their right--and not just an obligation!--to make sure that the project starts out on track and stays there. They feel privileged to be able to review each others' work, and to be included in each design decision. They don't dismiss it as a drain on their time; they value it as a way to make the project better. The project team as a whole buys into the direction of the software and its implementation. By taking part in these decisions, all team members end up feeling greater ownership and pride in the final product, and the team builds and releases better software.

Pages: 1, 2, 3, 4, 5

Next Pagearrow

Sponsored by: