Sometimes I am amazed by open source software... even as I contribute to it. The largest repository of public open-source projects, GitHub, has over 35MM repositories in it. Granted, some large percentage of those are private, and therefore closed-source, but even if only half of those are public, and by all accounts it is much more heavily weighted towards open, the numbers are in the tens of millions. Add in other source hosting locations like BitBucket and sourceforge, as well as privately hosted sites like GNU Labs' git.

Since the dawn of software, more or less, companies wrote their software in a process that went something like this: Product defines the specifications. Architecture designs it. Engineering/R&D builds it. Quality Assurance (QA) tests it. If it passes, it is scheduled for release; if not, goto #3. The jobs of QA teams historically have been procedure-oriented. Whereas engineers tend to be more creative and inventive, QA teams provide the process and constraints (remember the term "

Although the title for this article might imply suggestions for Proctor & Gamble's IT department, instead we will address how badly code can "smell" and how and when to prevent it. In business as in software, the concept of a "smell test" is a base instinct for if something is a bad idea or implementation: if something smells bad, it probably is. One of my favourite technology bloggers, Adrian Colyer, wrote a recent article about a fascinating analysis of open-source projects, primarily Apache, Eclipse and Android.