Like nails on a chalkboard

You know the feeling... someone says something in a meeting that just grates on you. You know it's not true and now you have a choice. Do you nuke them, politely point out where they've erred, or do you simply forget it and go on with life? I had the opportunity to review a slew of Project Management books recently and Applied Software Project Management by Andrew Stellman, Jennifer Greene was one of them.

Their phrase "All developers are created equal" grated on me in this way and initially I went with the third route, but when they recently wrote an article for OnLamp titled What Corporate Projects Should Learn from Open Source and then it made Slashdot, I had to respond.

Here is their explanation:


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."
[snip]
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.

While I believe whole-heartedly that Open Source projects measure people's usefulness and skill according to what they produce, I believe Stellman and Greene are missing an aspect here: On the Open Source project, nearly everyone will go through an experience similar to the Junior Corp Developer. It has very little to do with their overall experience level and everything to do with their experience level within the project*.

Within dotProject, there are regular requests to rebuild the system from the ground up, implement it in a new language (Rails is the favorite lately), redevelop things with a new model, and a general multitude of other requests from people completely new to the project. I probably even made a few of them years ago... but the point is that these requests are met by a very similar skepticism and doubt to that of the corporate environment. After all, "what does this new guy/girl know?"

The fundamental differences within an Open Source project are:

  • This new guy/girl can immediately start submitting patches in areas of their choosing as opposed to being assigned a position in a rigid org structure.
  • They can immediately review and participate in the discussion since these discussions are often archived in forums and mailing lists as opposed to trapped in other people's heads and buried in the documentation.
  • They can completely obfuscate/ignore the facts of their age, phsyical appearance, nationality, language, religion, etc, etc. instead of being a 13-year old working among grey beards.

The Open Source projects didn't immediately respect and value the opinions of these new people. These people still had to demonstrate skill and ability in order to prove themselves but their potential peers didn't have the noise.

Once you establish yourself, that's when your opinion matters.

* Well-established experts will not fall under this rule. If Tim Bray criticizes your use of XML, Chris Shiflett mocks your security, or the 37signals crew uses your project in a "UI Don't Do List", you might want to stop and review...

Not quite

While it is less common in many development shops, if you have a shop with a relatively rigid heirarchy, this sort of thing can be common.

Actually, one of the reasons I started CodeSnipers was to bring together people of completely different skillsets - who normally wouldn't interact - and see what ideas come out.

One other thing, though...

Is that some newcomer to a project, if they have the gumption, can always branch off their own version of the project and do things their way, whereas the junior developer is just plain SOL. (Or so I've heard. Nothing like that has ever happened to me wink wink nudge nudge).
Point taken, though. They did present a rather facile argument.