CTOForADay.com

I mean, let's be frank - I find it difficult, if not impossible, to believe that some of these basic things are still being discussed. These conclusions fall into three categories: Basic principles of software development, Basic best-practice in the software industry, and pretty dumb expectations.

Publicly releasing open source code will attract flurries of patches and new contributors.

That would be a pretty dumb expectation: Publically releasing source code does just that: it dumps a bunch of source code on a website. Any idiot for whom the other eight on this list were remotely interesting news to is going to have dumped an undocumented, untested, and probably non-working lump of crap onto an unsuspecting, blissfully unaware (and likely to remain that way) public. Nobody, but nobody, gets to the stage of releasing large software development projects without already having learned this lesson in the process of doing so. I don't know if this is aimed at some mindless middle management tier, but I certainly can't imagine this is a common misconception.

Stopping new development for weeks or months to fix bugs is the best way to produce stable, polished software.

This is one of those basic comments on the process of software development for people who've never been involved in a professional development team, or who've never actually 'done time' in community development of software. As such, I have difficulty believing this one could be a common myth. This isn't just "old road", it's the Roman Via, travelled for the digital equivalent of thousands of years.

New developers interested in the project will best learn the project by fixing bugs and reading the source code.

Anyone who's ever hired or a developer, or been hired as a developer, knows what an absolute nightmare coming up to speed on a project rapidly can be, and we've all been dragged kicking and screaming into projects that had no documentation and found just how hard it is to learn a project entirely by reading its code. As an aside: "It's got javadocs" is the most common three-word euphemism for "no" that you'll ever hear in your entire life.

As the world's most visible failure, Netscape taught us a valuable lesson. The whole of the Netscape open source browser project, which became known as Mozilla but is not the Mozilla we know today, failed directly due to this principle; none of that code survives to this day. Ten million lines of source code, down the bit bucket, because it was too complicated for anybody to contribute to; Netscape had failed, in a very expensive way, and the whole open source community learned this lesson in 1998, less than six months after the initial release of the Netscape source code. It's successor, the modern Mozilla browser, has no real code in common with its predecessor - just the knowledge and lessons learned from the process: that if Netscape, a commercial organization, had developed a product that it struggled to support and develop internally, it would be impossible to expect the open source community to assist in any real way. Nobody makes this mistake anymore - it's just not a modern myth. And at the time it was done, it wasn't an old myth - the birth of Mozilla was a first-of-its-kind moment on an order of magnitude never seen since; the people inside Netscape, underdogs who fought management tooth and nail to make it happen, weren't under any persuasive, mythological illusions - they just wanted to do what they felt was the right thing for the project and for the company.

Installation and configuration aren't as important as making the source available.

Anyone who's gone to a new job where the process of doing your first compile takes you days is going to make damn sure that any projects they start out on don't do that to them. I've joined countless teams now; in too many of them, I end up writing a build system as the first thing I do. For people that should know better, too. Making your own staff jump through hoops to compile and deploy is a guaranteed way to ensure that your product looks like hell when it gets out the door, and so professional teams just don't make this mistake; and neither do successful open source products. As a 'thing for newbies to know if they want to make their open source project successful', it's a nice tip - but I'm not under any illusions this is a common myth. Bad practice, yes - but not a myth. Just an all-too-common occurrence in a world where too many things which people refer to as "products" should actually be called "prototypes that cost money". Not a myth.

Bad or unappealing code or projects should be thrown away completely.

I'm torn on this. Mozilla threw away ten million lines of code, and it was the best thing that ever happened to it. An extreme example, and one that took two years to recover, but we wouldn't have what we have now without that decision. Then there's the issue of whether keeping a bunch of "reinvented wheels" does all that much for you: Let's be frank. A good deal of the code I've seen in projects is crap that other people did better. The whole point of the Jakarta Commons project and projects like it is to be a home for well-polished, well-tested wheels to help you replace your untested, poorly-treaded, hastily developed ones. Throwing away bad code and replacing it isn't evil. Creating unnecessary work for yourself is. There is, however, a fine line between the two - but we no longer live in a day and age where people should be reinventing wheels in the first place. At a higher level - nothing replaces good design. Even the professionals screw this up, and whole methodologies exist for integrating large-scale change in projects through short-term development milestones. This is either a "fact of life" (all things change in time) or an unfortunate side-effect of hiring an idiot, depending on your viewpoint, but again, not a myth.

It's better to provide a framework for lots of people to solve lots of problems than to solve only one problem well.

There's an old phrase that gets used in professional circles for as long as I have been a programmer: eating your own dogfood. Use what you make. If you produce crap, be forced to live with that crap. No bug gets fixed quicker than a bug that directly affects your developers. Providing frameworks without being a user of those frameworks is a sure-fire way to screw up your whole business. Life is more than test cases and theoretical software architecture. Again, not a myth; and I'll even counter by saying that there are some very good people out there producing some very good frameworks; the best of those frameworks are heavily used in other things they ship. From Apache to the Mozilla Foundation, OmniGroup to Zend, companies that produce good software almost inevitably produce good frameworks. It's a basic principle that good, reliable software is likely to be carefully designed, well-thought, well-planned, and most importantly, well-executed. Again, not a myth unless you happen to be 13 and spending too much time caressing a bottle of zit remover.

Even though your previous code was buggy, undocumented, hard to maintain, or slow, your next attempt will be perfect.

If you have a programmer who thinks he's perfect, fire him now, before it's too late. If you are a programmer who thinks he's perfect, it's time to put down the crack pipe and check into the Betty Ford clinic. Software development is rife with mistakes; these people are paid for eight (and generally many more) hours a day to write in something that looks to most people like demonic Tongues; miscommunication is a fact of life, and mistakes are an inevitable side-effect of breathing and having a pulse. Bugs are unavoidable. In short, Shit Happens. Show me a professional who doesn't know this. The only thing that's a "myth" about this is that it's a myth to believe that open source programmers aren't every bit as aware of this fact as professionals. Don't believe for a minute that the open source community isn't aware of how to structure projects and release high quality software. Project Management isn't rocket science either, nor is the development process itself some kind of mystical black art, even if your current project manager tries to make it appear as such.

Warnings are just warnings. They're not errors and no one really cares about them.

I have difficulty believing that professionals routinely screw this up. I have difficulty believing that open-source developers aren't professional, as all the ones I know are. Hence, I have difficulty in believing this is anything other than a guidance for novices - not a myth.

Users don't mind upgrading to the latest version from CVS for a bugfix or a long-awaited feature.

Show me an open source project that doesn't know how to ship a completed product, and I'll show you an open source project that isn't getting used by anyone. I find it difficult to associate this with the myth in question, however: if I'm asking you to upgrade from CVS, it means I've got more important things to do than ship. What this says: Either the build process sucks, there's no 'final candidate' test mechanism in the project (either due to lack of participants in the project or lack of staff in the company) or they don't care about end-users at all, and all they're doing is using a public CVS server because they're too lazy to set one up themselves.

Not much myth in that.