Note: this is my exit(0) column for the August issue of php|architect, written well before the recent WordPress worm hit many high-profile bloggers asleep at the upgrade switch. Besides the fact that, obviously, I’m a psychic and your company should hire me to divine its future, I thought that this piece would be particularly relevant to the discussion at hand. I’ll be entirely honest and say that I don’t like WordPress—but it’s also high time that people realize that if when you install a piece of software on a server, you also take the responsibility of keeping it up to date. Bitching at the WP folks because they didn’t make that process easy until recent versions is no excuse for the fact that you dropped the ball.
PHP is, as I am fond of saying, the language of people who get things done. Getting things done, however, doesn’t always mean that the end result will be pretty—in fact, I believe we can all agree that there is much “ugly” PHP code in the wild (and let he—or she—who is without sin write the first unit test).
What is interesting about ugly code is that, like a coffee stain on the new living room carpet, it just doesn’t want to go away—it sticks around, makes itself at home and awaits the next developer who comes along and notices it. Meanwhile, the underlying product thrives, becomes popular and grows—and so does its codebase.
There are a number of very popular open-source products that could arguably benefit from a good, old-fashioned code audit; in all fairness, there are probably a good number of very popular closed-source products that could probably benefit from the same—we just don’t get to see how ugly their code actually is. A number of PHP community members have, recently, analyzed the code that belongs to several PHP-based OSS packages—content management systems and e- commerce engines seem to be popular targets—and determined that many of them ignore common best practices and contain code that is either poorly documented or difficult to maintain.
And yet, these packages thrive. They build huge communities, gain large followings and, generally speaking, often become the catalyst of bona-fide revolutions in their markets. Some of the most popular content management systems are PHP based and have grown organically from very humble beginnings—which they still retain, at least in part, to this very day. Far from being a liability, the perhaps less-than-stellar coding standards have, in fact, become assets: programmers who collaborate on these projects are encouraged to look for results without placing undue emphasis on form.
There are, of course, limits to the tolerance of the “relaxed” coding practices that these projects have. The implosion of phpBB that happened a few years back—when even Google was forced to intervene in order to stop a worm from causing widespread damage—sent out a very clear message: security is not something anybody can compromise on, regardless of how inexpensive or popular their product is.
By and large, however, bad code is a phenomenon that matters little, if at all, to the end user—it’s the results that make all the difference. Several open- source PHP CMS systems have functionality that rivals—and in many cases far surpasses—their commercial counterparts without coming with the same steep (and, let’s face it, sometimes absolutely ridiculous) price tags.
What can we learn from all this? Simple: that we need bad code. The importance of peer review and critique is important—and, therefore, so is the work of those community members who are taking the time to examine the code that is found in these open-source projects—but so is the unique ability that many of these products have demonstrated in building features, attracting communities and gaining a popular place in the marketplace.
What is really great about this line of thought is that the existence of bad code is, in fact, a win-win for everyone: users get what they want at a very low cost; developers can learn to improve their code from their peers; and community members can learn from each other how to build code that others want to use.