Just about every programmer prefers writing their own code to maintaining somebody else’s. This is even more true in the open-source world. You get to choose your language, your libraries and frameworks, your style. Do you prefer Erlang or Ruby? Shared state or message passing? Long variable names or short? Many exceptions or few? Whatever you write will use all of your favorite toys and tricks, be sophisticated where you think sophistication is called for and simple where you think simplicity should be the rule. Even if you have to maintain it later, it’s still more fun than fixing bugs in someone else’s code representing someone else’s priorities and aesthetics. Writing a big new blob of code might be considered a negative a company or project, but to the individual programmer it’s almost always considered a positive. I don’t even have a problem with that if entertainment or self-education is the admitted goal. Heck, pretty much all of the code I’ve published here has been written that way, and I’ve generally been careful to admit as much. If you write code because you enjoy it, that’s great. What does irk me, though, is when people write code for fun and then try to pretend it was for something else. “Scratching an itch” is merely a euphemism for what such people are usually doing.

One common excuse for writing new code, or rewriting old code, is that the new code is supposedly more maintainable. There might even be a grain of truth in that, to the extent that maintenance requires understanding and it’s generally easier to understand your own code than to understand someone else’s. That only works as long as the person who wrote the code is still around, and still interested in helping. Usually the same people who are quick to reimplement one thing are also quick to drop that project and go off to rewrite another. How many of the people reading this have, at some point in their careers, had to pick up a pile of crap code left by some attention-challenged goatee-wearer who left the company to work somewhere more fashionable? Pretty much all of those over 30, I’ll bet. The potential maintenance benefits of locally developed code should always be weighed against both the initial development cost and the risk of it being less maintainable when its author leaves. As a general rule of thumb, the effort required to rewrite or replace code should be estimated and no such project should be undertaken until its advocates have spent at least as long learning what problems the old code really solves. (Side note: this also applies to NoSQL projects in general, and specifically to why I’m not writing my own Dynamo derivative.)

The other popular excuse for writing new code here is performance. “XYZ will be much faster” is one of the most common things I’ve heard from coworkers. Maybe I’m jaded, but my reaction nowadays is likely to be either “Who cares?” or “Why should I believe that?” I say “Who cares?” not only because performance is often not a relevant figure of merit, but because it’s generally system-level performance I care about. Really, if the part of the system addressed by XYZ isn’t the bottleneck, making it faster is just making development slower. Even if it is the system-wide bottleneck, making it faster might not help. It’s often possible to make something faster by letting it use ten times as much memory, for example, but often that’s effectively a resource stolen from some other part of the system and the net effect is not worth the development effort. Squeeze one part of a water balloon and another part bulges out. That might be fun, but it’s not productive.

Even more important than measuring performance at a system level, though, is measuring it at all. The burden of proof for performance claims is on those making the claims, not on those who express skepticism. If performance is purportedly the reason for doing something, you should be able to measure that performance the moment the code is written. Don’t expect others to do it for you. That’s not collaboration; that’s laziness. “You can try it yourself” is particularly offensive when the languages and libraries etc. to do so are lying there in your sandbox but don’t exist in any standard distribution and have to be built from source. Anybody who uses performance as a justification without even being able to define what kind of performance, measured under what conditions and compared to which alternatives, is just a dilettante. Even a back-of-the-envelope calculation – of cycles, messages, seeks, or whatever tends to affect performance most in your particular domain – is worth more than empty claims.

As I said at the beginning, if you want to write new code for fun, knock yourself out. If you want to write it first and then explore its characteristics later, that’s fine too. That’s a form of research that I’d never discourage. Just don’t expect me or anyone else to be impressed by the mere fact that you wrote it, or that you wrote it in some particular style. The proof is in the pudding, and I’m hungry.