- Image by Balakov via Flickr
In The importance of bad code (or, WordPress and why I am a psychic), Marco Tabini proposes the idea that we need bad code. Or at least that we should be tolerant of bad code in open source projects because that invites participants that might otherwise not contribute.
This is an interesting idea that struck me as novel. But after thinking more about it, I believe it’s not a radical departure from what we’re all implicitly accepting, no matter how fanatical we might be about clean code.
Luke Welling’s comment to the blog post is particularly enlightening and worth quoting in full:
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.
I commented:
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.
Perhaps even more important is the question of whether and how to keep a clean separation between good and bad code. Bad code becomes a problem to me mainly when I need to maintain bad code written by others. Not that I dislike it so much; I sometimes enjoy cleaning up messes, but it slows me down. But if the person who wrote it is maintaining it, it doesn’t affect me much. So a clean separation would be helpful.
That also makes the whole issue clearer to me. Most of us use operating systems, library software and applications that aren’t necessarily up to our coding standards. Having lower code quality in parts of a project is not much different in principle. In fact, it may be less of a problem in some cases. When you a program library that has code of poor quality, the good code is dependent on that bad code. If you are programming the core of an open-source project and someone else is adding bad code in the form of an extension, the bad code is dependent on the good code, making it even less likely that the bad code can affect the good code.
In Domain-Driven Design, there is a pattern called Anti-Corruption Layer which can be helpful in preventing the bad code from having an undue influence on the structure of the good code. It’s worth thinking about, especially when the bad code has an illogical and confusing API.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_a.png?x-id=eb6b55e2-85da-88bd-a263-dc329004c320)
My approach to PHP is often ugly I’m sure, glad to know I am still welcome though
I’d have to agree that of coarse clean code and standards should be an important goal for every programmer. BUT just as important is encouraging coders to take a chance and be creative. Try something new but realize that there is always a better way and don’t stop learning how to be better at what you love to do. I’ve been coding for quite a few years now and even though I know my early work is spaghetti it stirred my creative juices and is still being used quite a bit 6 years after I originally started writing it. I jumped in and made it work however I could. When you create something useful that people actually use every day it’s encouraging. I’m learning new stuff everyday. Having to maintain my own application is what spurred me on to be a better coder. Encourage better coding practices by mentoring and encouraging others in your language of choice.
@ Rois, i have had exactly the same experiences. I’m now going back and refactoring one of my earlier spaghetti-code applications and trying to find even better (and hopefully cleaner) ways to do things.
@ Marcas, I’m pretty sure my stuff would be considered ugly by many of the thought leaders in the PHP field, but its light years beyond where I started. There’s so much space between newb and expert, I’m not sure any of us really get to the end of the journey.
Interesting idea and definitely some truth to it. Of course the question is what is bad code?
If bad code is like “hardcoding” in places where it shouldn’t happen, and maybe some inefficient loops, calls to the DB, but if the overall architecture follows a good pattern and process then “bad code” is acceptable. You can eventually work on this later on when optimizations and refactoring is needed.
On the other and, if by bad code you mean redundant coding, no particular patterns… I don’t think this is ever good.
I would take the approach that acceptable “bad code” is the kind that doesn’t mean you have to do a complete rewrite if the application takes off, grows in size. If it limits growth because it’s just hard to change and understand, that’s bad code that I wouldn’t want
.
nice article btw!
Not only do I agree with the comments about bad code, I know developers become better by writing bad code. I can remember the days of bloated functions with several lines of code. Now look back and see that I should have pulled some of that code out and make a few separate functions instead of having one function perform several tasks. Without that painfully bloated function, I wouldn’t see the value of a function perform one task.
Hi Chris, I’ve been programming PHP for a couple of years. My bad code isn’t intentional, but without being able to afford certain software, it’s the only way I can do certain things. Maybe it isn’t even that bad anyway, no one has ever really looked at it to tell me. I feel if it does the job quickly enough then it’s alright by me, and my users will never know.
@ Maracas. I’m pretty sure nobody ever intends to write bad code, myself included. I think the #1 spec for any job should be “does it deliver the functionality the customer wanted?” The elegance of the solution is secondary to actually achieving the desired outcome. We have the luxury of then going back and making the code prettier later as we learn better ways of doing things.
I think bad code is a greater phenomenon among us solo developers. Folks working in teams probably have a lot more processes in place to mitigate code that doesn’t fit their agreed upon standards.
In the end, much of what makes code “bad” is subjective, and we’re only talking about this because a group of seasoned PHP developers have gotten together (albeit not formally around a table) and over time decided what “good” code is.
Ultimately, “good” code is just a suggestion, and though I have no beef with most of it, I do reserve the prerogative to do things my own way when I disagree with the accepted standards.
most important requirement of any code or piece of software is to perform a task or set of tasks
if the code is performing / doing the assigned task successfully, then coding practice is seen next
bad code can harmful, but no. 1 priority is functionality