The Muratori-Martin debate: Clean Code, yay or nay?

What's Clean Code to you, programmers? To some, it's the Holy Grail of programming, a state to strive for at all costs. To others, it's a pain in the butt and an impediment to getting shit done.

Many others, like myself, I suspect, fall in between these two polar extremes - Clean Code is a good-to-have, but should be sacrificed when needs must. Because all programmers have to work within the contexts and envoironments they are given, and not every one has the luxury of making demands. Code exists to add business value, period. Nobody pays programmers to write beautiful, clean code for the sake of it, or take as long as they like writing said beautiful, clean code.

Do you have a moment to talk
about our Lord and Savior
Clean Code?

That's not to say that code shouldn't be beautiful and clean; far from it, but it shouldn't be the primary or overriding goal, at least not in the business context. It certainly shouldn't be treated like some sort of religion.

If you're given the choice of speed of delivery, performance, or Clean Code? what do you choose? If you say "all of the above", chances are you'll get none of the above.

Casey's take

One Casey Muratori falls squarely into the anti Clean Code camp. He recently took to YouTube to rant about Clean Code and how it's ruinous to his profession - that of a games developer.

In the video, he goes through the principles of Clean Code, such as (paraphrased):

1. Use Polymorphism instead of If blocks or Switch statements.
2. Hide the internals of a class.
3. Keep functions small.
4. Functions should do only one thing.
5. Don't repeat yourself.

And then he proceeds to eviscerate most of them by example, showing how much Clean Code slows the program down. Also, how breaking those rules could actually improve the code. I have to say, that was educational. And a real eye-opening live example of what I always like to say - there are no blanket solutions. One programmer's Clean Code is another's garbage.

Casey Muratori vs Uncle Bob

Cue the Clean Code fanboy outrage!

And what bigger Clean Code fanboy than "Uncle Bob" Robert C Martin himself, the author of Clean Code (which I regrettably haven't had the pleasure of reading yet)? I was alerted to the debate that had sprung up on GitHub after doing a Google search, and immediately forked that branch so I could catch up at my own leisure.

Crossing swords.

In it, Martin took on Muratori in a vigorous debate, filled with examples and counter-examples, and one amusing aside about GitHub's interface speed.

At the end of it, Muratori had this to say:

So if I had to restate the summary, I would say:

• We both agree that complete hiding of implementation details can be useful, and that people should know how to do it.
• We disagree on how often they should be hidden; you think the answer is "most of the time", I think the answer is "only in specific circumstances"
• We disagree on how important the computer is. I think we need to think about the computer most of the time, whereas you do not.

In Martin's closing statement...

In my work I don't care about nanoseconds. I almost never care about microseconds. I sometimes care about milliseconds. Therefore I make the software engineering tradeoff towards programmer convenience, and long term readability and maintainability. This means that I don't want to think about the hardware. I don't want to know about Ln caches, or pipelining, or SIMD, or even how many cores there are in my processor. I want all that abstracted away from me, and I am willing to spend billions of computer cycles to attain that abstraction and separation. My concern is programmer cycles not machine cycles.

... and this.

I tip my hat, however, to your valid concern that myopically focussing on programmer cycles and utterly ignoring computer cycles can lead to horrifically inefficient systems. None of us want that; just as none of us want to work in a world where we focus solely on computer cycles to the detriment of programmer productivity.

I marvel at how classy and professional this exchange was. I've known people to get outright nasty about their geek credentials, and I've worked for code purists who constantly derided my code for not being clean enough. This debate showed me that people are capable of not making things personal where their work is concerned. That said, Robert C Martin does have a reputation to uphold, and he's probably not dumb enough to tarnish his own legacy with a public hissy fit.

Some will differ as to who won the debate. I don't think there was necessarily a winner in the classic sense - both acknowledged each other's viewpoints but retained their own opinions. If there was a winner, it was probably everyone who was privileged to witness this.

My takeaway from all this...

I hold Robert C Martin in high regard. How could I not? The man's accomplished more than I ever will, in my own industry, at my own game. And reading his work, there's this sense that I will never live up to his standards.

But here's the thing - do I want to? Should I even want to? Uncle Bob and I work in the same industry, yes, but we also work on vastly different things and with vastly different things at stake. It's like comparing a skateboard to a bicycle... not that I would ever seriously compare myself to Uncle Bob, or him to a bicycle.

Clean Code has its place. But as with most things, we should not accord it more importance than it deserves.

Cleanliness is next to Godliness!
T___T