Wrong, wrong wrong. A kid fresh out of college IS NOT equal to somebody who has been working for 20 years. NOT EQUAL. I'm sorry if that hurts somebody's feelings, but that's life. To assume that "all developers are created equal" is completely and utterly wrong. I don't know how better to explain it; this is kind of a common sense thing.
This is a common fallacy that equates years of experience with intelligence. While it is true that years of experience can help a person become better at their profession, would you rather have a doctor without a medical degree who has been practicing medicine for 30 years in a small African village or a young doctor who recently graduated from Johns Hopkins Medical? While this is an extreme example, it proves a point. Experience, in and of itself, does not equate to being skillful. A great modern success story is that of Google founders
Larry Page and
Sergey Brin were both under the age of 30 when they founded Google. I am sure there are many companies which would have dismissed their ideas because they were "inexperienced".
With this being said, the article makes a valid point. While that fresh out of college programmer may not have years of experience, they may have a different knowledge base than the experienced programmer. Thus to dismiss an idea of an inexperienced programmer based solely on their experience level is unwise and leads to many great ideas being ignored. I believe the point the author of the article is trying to make is that in sucessful open source projects, ideas are valued over authority.
The fastest way through the project is to do it right Huh? No it isn't. The fastest is often to slap together something crude that works. It's all about ROI. If I hire a developer to write a quick and dirty DB interface that only I use, and he takes 6 weeks to do it, because he's sharing and holding hands, and documenting, and using source control, etc., then that developer will be fired.
Yes, you have found a situation where this type of development process may not be necessary. I don't believe the article is talking about simple applications that are of limited outside utility, but about complex applications that require collaboration among many programmers. The article is making a point about how applications should be developed within
teams and not about a single person developing a one-time use application.
When it comes to developing software within teams, the author makes valid points. Really, the article is about best practices that should be followed when managing any complex projects. Is the methodology described exclusive to the open source community? Absolutely not. Are their failed open source projects? Absolutely. The author is writing about best practices from sucessful open source projects, not failed open source projects.
What I think is amazing is how many project managers think things like documentation and collaboration is a waste of time and money. By analogy, when a building is built, we don't think it is a waste of time to hire write up a blueprint before the building is built (requirements documentation). We don't think it is a waste of time to coordinate efforts so the persons putting up the walls don't do their work before the electrical is put in. We don't let buildings be inhabited until a building inspector comes in (quality control). So why do we think we save so much time and money by avoiding these obvious best practices in software development?
As an example about how careful design can save money see
Correctness by Construction: Better Can be Cheaper.
