0WNZ0RED

Don’t be alarmed.

Helpful Tiger has not been hacked.

No one’s going to take my home page and rewrite it so it’s filled with pictures of the Janet Jackson Maneuver from the Superbowl.

But I have been thinking about a certain kind of rewrite: code rewrites.

Joel Spolsky’s article on rewriting is clear: don’t throw away your old code and rewrite it from scratch, ever. No one appears to be arguing with him, and yet I’ve seen throw-away rewrite after rewrite, over and over again.

Why?

What’s in it for the developers?

One word: ownership.

When you rewrite code, it becomes yours. You’re invested in it, more focused on it, more willing to go the extra mile for bugfixes and enhancements.

This is the real benefit of rewrites. You may be able to convince a manager that the rewrite improved things, despite Spolsky’s arguments, because the rewrite improved you.

So how do you get those benefits without the downsides? Here are my thoughts, in no particular order, but phrased in the imperative, for both your and my consideration.

Enjoy!

Version 2 Syndrome
OK, so you’ve inherited a codebase. Most of the time, developers are already forced to work with such a codebase for a while before rewriting it. It’s only after the first new release is out the door, where they’re familiar enough with it to know its faults, but still not necessarily invested in it, that big rewrites get proposed. One idea for managers is to say: “Version 2 must still be based on the original codebase. You want to make changes? Propose them to me in terms of a series of changes to the existing codebase.” The challenge of implementing that may lead to more investment, more ownership.

Bye Bye Birdy
If you are going to allow a rewrite, don’t assign it to a developer who’ll be off the project in a few months. You’ve wasted your only concrete benefit! Same goes for “troubleshooters” brought in to fix a project on the ropes. Let ’em propose new designs, but let the developers who’ll be staying on the project do the work.

Square Peg
Some developers are just extraordinarily good at solving problems. They need to be challenged constantly, always chasing that Eureka! moment. And then the rest of the team is left with code that works, works really well, but nobody else understands. Such developers will never own anything. Trying to tie them to ownership is putting a square peg in a round hole. Put someone else in charge of that code, ASAP, so they can figure it out – and put questions about it to the original developer while she or he still remembers it. It’s an extra cost to involve a second developer, but it will be worth it.

Institutionalized
If a large, complicated codebase belongs to a company, but all the developers who worked on it have left or been abruptly transferred, it’s as if the company doesn’t really own it anymore. That may have been part of the problem with Netscape. The people who had owned the code weren’t in charge any more. Avoid this. Don’t move people around if the benefits – what, say, a certain developer can bring to a new project – don’t outweigh the costs – an eventual rewrite of another project’s codebase when major new functionality needs to be added.

This brings up the question: how do you transfer that real feeling of ownership? I don’t just mean formal responsibility, I mean the state of affairs where the new developers feel as invested in the code as the old ones did. The exact transfer process might be less important than finding the right kind of developer, willing to learn and commit to something external.