ndanger.organism

Jeff Atwood says that nobody cares what your code looks like, which–despite Jeff’s absolutely hilarious Joel Spolsky diss–is something Joel also talked about.

Ok, your customers don’t care what your code looks like… but they probably do care what it does. So saying “code beauty doesn’t matter” is the same as saying “ugly code works just as well as beautiful code”. You could argue that if the tests pass it’s all the same. But most customers also care about how well your code will function in the future. Does anyone really think that ugly code is as easy to change?

The agilists would say that ugly code is Technical Debt (well actually they would say that smelly code is technical debt but that’s irrelevant). Like real debt, technical debt accrues interest. Bug fixes muck up its guts and new features build on its interface, and, if your code is hideous, it’s a fair bet the interfaces aren’t much prettier.

But if we torture the metaphor some more (though I don’t consider this #2), debt can be a valid growth plan, just ask 90% of startups. Debt (technically selling your future worth for venture capital) is betting that you can run fast enough to reach profitability.

For code it’s hard to imagine you can build a critical mass of ugly code that will suddenly become beautiful, in fact that probably violates the second law of thermodynamics. In companies where speed & features are tied to lifespan (via convincing people to give you money), however, a fortune might let you amass a big enough army that you can reach that asymptote. Some people seem to be using the strategy, though it’s questionable how well that’s been working.

What of open source? For a commercial company where open source is largely a “look, you can see our code, so no lock-in!” feature, like Jeff’s example of his friend at a “large open source database company”, technical debt functions almost the same as in a closed-source company. I’d argue that it’s a bit worse; some people still eat fast food after having worked in the kitchen, but most swear it off and tell their friends that it’s full of tubes of grade E meat and cockroaches. It’s especially bad if your customers are programmers.

And if you want people to contribute to your open source project…

Despite what some people who inherited my code might think, I’ve always been a fan of beautiful code but I’ve come to understand the economics of “screw it”. But I think that the two can be rectified.

A small example to conclude. When I was in school I interned working on a speech recognized written in C (it was for an embedded device). Every new feature or bug-fix I worked on had an accompanying local code-cleanup. Ultimately I did a massive clean-up on the audio front-end, touching something like 75% of the file, and remember that this was a C file (i.e. it was big). The code review spanned two day but afterwards the code was smaller and, to everyone’s agreement, cleaner. I don’t have any metrics about it reducing bugs by 20% or anything, but I’m fairly confident it was worth the cost: about 1 full-time developer day and about 1 part-time intern week.