All Developers Are Created Equal
Say a junior developer is working on a bug fix, and realizes that the entire design of the part of the software he's working on is flawed. He comes up with an improvement and brings it up with his boss. If this is a typical corporate project, it's likely that this junior person will see his idea shot down almost immediately. His boss will brush him off, saying that it will take too long to implement, or that it's going to be too hard a change to make, and nobody else on the team will even hear about it. But what his boss is really thinking is, "How can this junior guy spot a mistake that none of the senior people caught? He must not understand all of the details."
Say that same junior developer later that week brings it up with a senior team member. The senior guy is in a good mood, and entertains the thought. Suddenly he realizes that there really is a serious problem with the project! He goes to the boss, but this time the boss listens. With the senior person's backing, the suggestion has a lot more credibility. Now it will be heard and acted upon.
This is no way to run a software project. Good ideas come from everyone, not just the senior team members. But corporate environments frequently discourage innovation from the "bottom of the food chain." In fact, many corporate environments discourage innovation altogether, dismissing it as risky and potentially expensive. There's often a sense that no new innovation should be adopted unless it has been successfully implemented in another project. This is yet another way that team members' opinions can be squelched on corporate projects. In the end, many bright (and often young) project team members routinely come up with new and insightful ideas, only to have them shot down because they didn't follow proper channels or have enough seniority--or because a senior manager simply didn't understand them.
This is another area in which corporate projects can learn from successful open source ones. Blake Ross, a 19-year-old hacker, started the Firefox project when he was dissatisfied with the way the Mozilla project was going. And he's not alone. In Producing Open Source Software, Karl Fogel points out that open source teams judge their contributors solely on their code contributions and their posts to mailing lists, message boards, and discussion groups. He relates the story of a respected GNU Emacs contributor who turned out to be a 13-year-old living with his parents. No corporate project would ever give either him or Ross the time of day, yet the open source teams treated them both with respect solely because of the quality of their work. Open source project teams adopt a philosophy of treating all developers equally, judging them solely on the basis of their work.
The Fastest Way Through the Project Is to Do It Right
Even when corporate managers have acknowledged that many of these practices are useful, and have put together a software process that uses them, they may routinely ignore their own rules when they feel like they are under pressure. As deadlines get closer, management looks for ways to "trim the fat." They cut any practices that they feel don't actively contribute to the bottom line, often starting with reviews (the very thing that makes many open source projects so successful). If a project is running late, many important activities start to seem frivolous to many managers: that three-hour meeting that brings the programmers together to review the architecture or new patches, the important refactoring exercise that improves the design of an important object, the building of automated unit tests to catch bugs before the software is shipped. They'll argue that these things are too expensive to "waste" those programmers' hours on. Programmers are told to cut any activity that doesn't directly produce code.
When this happens, the team is forced to cut the two-hour meeting that would have saved them from wasting weeks going down a wrong path. Or they don't spend four hours writing unit tests, which would have prevented serious defects that eventually cost days of time and delayed the ship date. Thinking about how to do the work before doing it is always faster than blindly plunging forward.
Well-run projects require a lot of collaboration. Much of that collaboration is understood and planned from the very beginning. Team members need to talk about the work they will do, and they need to keep talking about it to make sure they're on track. When a programmer writes code but doesn't fully understand its purpose, he ends up with an overcomplicated and unmaintainable code base, because he inevitably goes down many wrong paths that can't be fully undone.
Many poor-quality architectural decisions have been made by "locking" a programmer in an office and telling him that the only thing that matters is the code he writes. He's told by his well-meaning boss not to waste his teammates' time with reviews, and he's told not to "overthink" the problem and to just build the most obvious solution. This is a recipe for disaster when trying to build a complex system.
The reason that most teams agree at the beginning of their project to build the software in a way that involves a lot of communication, collaboration, and review is that those are practices that work. Any time that they're circumvented, treated as frivolous, or cast aside as "overengineering," the project suffers time delays. Every mailing-list post, every team meeting to discuss a design decision, every knowledge transfer session between a senior and junior team member, and every single review saves more time than it costs. Yet when a boss feels that his project is under pressure, these are exactly the practices that are cut out in order to "save time." This inevitably leads to a great deal of rework that could have been avoided. By dropping these practices, he's showing the team that he values time spent writing bad code over time spent avoiding it.
In contrast, open source projects don't compromise on time-tested practices. They tend to have strict rules about how a new contributor joins, what privileges he or she gets, how defects are tracked, how changes get reviewed and are handled, and how changes in the direction of a project are made. The team even has rules on how to change those rules. Even when the project is facing pressure, like when there are public and embarrassing bugs that need to be addressed right away, the team does not deviate from these rules. The reason that people are so determined to stick by the rules is that everyone feels ownership of them. Team members came up with the method of working, and everyone accepts the ground rules when they join the project.