⇥ The importance of bad code (or, WordPress and why I am a psychic)
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.
Comments
I'd argue that bad code is often a sign and a side effect of a thriving, welcoming user community around a project.
The OSS projects with good code tend to have a relatively small group of committers doing nearly all the work. There is a big learning curve to working within the project's (probably unwritten) architectural guidelines, and a big reputation curve that a new person has to climb to get their patches accepted.
Bad code is often a sign of welcoming new contributors, taking patches that do something useful even if the approach is ugly.
We all know the problems bad code brings, but I would argue that some projects are not just successful in spite of bad code, but successful because they allow bad code.
Wow, this is interesting. Although I've reflected on what we can learn from bad code, I've never thought of it in quite this way. Certainly, you can have huge success with bad code. And yes, the social structure of an open source community may make bad code more viable.
If we're looking for the optimal strategy (which is likely to depend a lot on the specific project), the question may be what parts of the code need to be held to high quality standards, and what parts don't require such strictness. And how to separate the two. Security is one of the key issues, since bugs can hide in bad code, and some of those will be security bugs.
I don't find this too unusual an idea, but I think that's because I don't have a formal background in programming. If your focus is from the user side, and you just care about whether it works or not, then the code really doesn't matter.
Except when there's security issues.
Except when advancing the architecture of the application is impossible because of the bad code.
Except, except, except.
But if we really take to heart the lessons of the Cathedral and the Bazaar, accruing bad code, and then cleaning it up later, is what any interesting app that floats around the bazaar ought to be doing.
Or to put it another way, the level of forethought required to avoid bad code entirely, smacks of Cathedral like planning, and that doesn't sound very "open source" to me.
Maybe that's just another way of saying what Luke said…"Bad code is often a sign of welcoming new contributors, taking patches that do something useful even if the approach is ugly."
I think it's more than that though. Depending how strongly you believe in release early, release often, you might be more or less willing to create bad code yourself, if not consciously then as a side effect of very open, agile techniques.
Let's not forget that there are more than two kinds of code too…it doesn't all line up into good code and bad code categories. What's unacceptable code for one purpose might be just fine for another.
A link to worse is better seems appropriate:
http://www.jwz.org/doc/worse-is-better.html
–Julian
As long as the code can be rewritten or refactored it's ok for it to be *bad*. But exposing a bad Api or using a coupled, horrible architecture is not so useful to bring in contributors…
> but I would argue that some
> projects are not just successful
> in spite of bad code, but
> successful because they allow bad
> code.
That may be true but it doesn't make it right, nor forgiveable.
Also, does that explain why Microsoft is such a success despite their explicit nature to so many bugs?
We have best practices for a reason and there is no excuse for lazy, crude and uneducated developers – more so today with so many underlying APIs being taken advantage of.
If a community is built on bad code, it is a poisonous community. Avoid it.
The only real time “bad code” becomes a problem is when a large company uses a free open source project that contains some of this “bad code.” Then they spend countless hours and money on fixing the problems themselves. It’s a deception really. They believe they are getting something for free when they aren’t. They are still paying developers to perhaps “modify” or “fix” the application if not actually “build” it. Decision makers are sometimes not programmers and don’t understand the web so when they see marketing material from open source CMS’ and other apps on the net – they easily get fooled with the pretty pictures and “ease” of it all. They assume sometimes even that their developers are no good and blame their -own- internal team for bugs and problems when their own developers are already at a handicap and are forced to work with “bad code.”
As developers, it’s our job to educate the community and decision makers and business owners and stakeholders so we don’t mislead them.
I’m just saying it doesn’t need to be all bad and we have to very responsible when and where we do use this “bad code.” A personal side is one thing. A big company site…Well, shame on them. They should know better and they should have the budget…But, it happens…
Take a look at recent developments with the PHP frameworks. CakePHP, Code Igniter, Symfony even and many others. They adhere to standards and paradigms. They focus on quality. While there’s TONS of debate on as to which one is better – I personally believe it’s a personal preference really. It’s still a VERY VERY far advancement from things like WP and Drupal and Joomla and phpBB and on and on. I hope that these popular CMS’ and apps that have clout and visibility would one day utilize some of these PHP frameworks so that we can start introducing some better quality. Sure, you can have “bad code” very easily within one of these frameworks – as rigid as some may be, ultimately the programmer CAN use it poorly and write bad code. HOWEVER, contributors who feel the need, can improve it and bring it back up to par more easily because there is actually a standard to follow, a guide, a paradigm, a model. I hope that’s the way things go…
I’m not saying frameworks are the end all be all. I’m not saying that they never had “bad code” either…BUT, they are a step in the right direction. The entire intent of them is what we all need to take a lesson from in the very least if we aren’t going to use them….And I don’t really expect WP and Drupal and so on to go and switch over to a framework. It’d be incredibly smart of them….but also incredibly difficult. I do think we’ll see more and more use out of frameworks in the future. Take Ruby on Rails or .Net or Flex for example. They did wonders for ASP and Ruby and ActionScript. Sometimes even made a name for the language. So why in the world do people hate on PHP frameworks?? Who knows. I just hope that we do get less and less “bad code” the purpose it servers is history and education. I think by 2009, 2010 even now, we’ve learned enough.