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.

Dean Wampler blogs: Is the Supremacy of Object-Oriented Programming Over?

“The fact is, for a lot of these applications, it’s just data. The ceremony of object wrappers doesn’t carry its weight. Just put the data in a hash map (or a list if you don’t need the bits “labeled”) and then process the collection with your iterate, map, and reduce functions. This may sound heretical, but how much Java code could you delete today if you replaced it with a stored procedure?”

After the previous post in this series, additional independent implementations of the idea of JavaScript-style classes have turned up. So I’m going to list them and comment briefly on the differences. I hope this will be helpful to anyone who actually wants to use this in practice and needs to decide on the details of the implementation. Here are the links in chronological order:

• Ionut G. Stan:Javascript style PHP with PHP 5.3.0 (forum posting).
• Fredrik Holmström: Javascript-OO & Python-DuckTyping in PHP5.3.
• John Mertic: What’s new in PHP V5.3, Part 2: Closures and lambda functions.
• My own previous article.
• Andrea Giammarchi: A JavaScript Object Like PHP Class.

One difference is how JavaScript-like the implementations are. Some of them implement a syntax that is deliberately made to resemble JavaScript. Andrea Giammarchi’s version even uses ArrayAccess to make it possible to access object properties using both object and array syntax, as in JavaScript. At the other extreme is my implementation. I’ve tried to make it as similar to a regular PHP class as possible. You can instantiate an object in the same way as with an ordinary PHP class. This comes from defining the methods inside the class constructor.

After seeing all of these, I prefer my own way of doing it, except that it lacks what I mentioned in the previous article: an exception when you try to call an unrecognized method. But I’m obviously not objective, and I may have have missed something.

Automobile skeptic: Driving doesn’t always work. I tried it once and crashed into a tree.

Automobile zealot: How did that happen?

Skeptic: I was driving down Hazel Street, reading a magazine. And then suddenly, out of the blue, I hit the tree.

Zealot:  But you can’t read magazines while driving a car!

Skeptic: Why not?

Zealot: Because then you’re not paying attention to the road ahead of you.

Skeptic: So what? I’ve familiarized myself with the driving process, I’ve even read a book about it. Nowhere does it say you can’t read magazines. Clearly, you are blinded by your own religious convictions. Whenever driving fails, you driving zealots find some way to explain it away. No logical argument will ever make you admit that driving can cause problems.

Too many conversations about agile development methods resemble this one. I came up with it after reading a column by Andrew Binstock called “the Zealots of Agile“. Binstock is merciless:

The agile movement has been nothing if not evangelical, even messianic, since its inception. From its founding with the publication of a manifesto (a manifesto!) to its subsequent, continual attack on the so-called waterfall model, agile and its exponents have hewn closely to the position that theirs is the one true path. And, consistent with this evangelical view, those who disagree either don’t really understand agile or are irretrievably deluded. For the deluded, only spectacular failure of their project will open their eyes.

In a blog post, Uncle Bob argues in detail why this is inaccurate and calls it “a load of dingoes kidneys”. But if it is, why does this particular load of dingoes kidneys keep getting dumped in this particular place?

Above all, it’s inevitable. Anyone who pioneers something radically new and different has to be prepared for this kind of accusation. Agile development is a paradigm shift, and paradigms are, to a large extent, mutually incomprehensible. We may all be “religious fanatics” if seen from the perspective of a different paradigm than our own. To some extent, we all resist challenges to our basic assumptions, and this is always easier to see if you don’t share them.

The problem is not that some are skeptical of agile development processes. That’s unequivocally a good thing. Being too quick to label someone else as a fanatic is not so good. That’s an effective way to stop fruitful discussion and learning. I’ve also noticed (in general, not just on this subject) that those do this are often stuck on a particular point of view themselves. Also, they sometimes seem to believe that they are totally free of prejudice and irrationality themselves. But of course, they aren’t. No one is.

Binstock’s fallacy is a misunderstanding of the aims of agile leaders. A religous or ideological fanatic is obsessed by being right and by convincing others of their own rightness and righteousness. In contrast, there are those who are passionate about principles and practices because they want to do better. Often, being right or wrong doesn’t really matter to them. I think Kent Beck, Robert C. Martin and others not mentioned by Binstock belong to the latter category.  But if you place them in a confrontational setting, you gain licence to misinterpret their behavior as an attempt to be right. And it seems to make sense. In the real, pratical world, changing your mind without mentioning it typically just means that you’ve learned something. In the artificial world of confrontational debate, it looks like an evasive tactic.  In the real world, explaining why failure happens is a step toward improving your process. In confrontational debate, it can be seen as an attempt to explain away the shortcomings of that process.

The confrontational framing of the situation is logically consistent, but rests on a false assumption: that it is in fact this kind of game the agile leaders are playing.