Home | Business News | Browse by Publication | C | Computers in Libraries

How to rewrite software--and when not to.

Article Excerpt
Nobody ever accused me of being a great coder. I've picked up some skills over the years and have seen little decisions lead to big problems, so I've learned a lot of what an experienced programmer should know about the fundamentals. Do comment on anything nonobvious. Don't repeat yourself. Do use consistent names for classes, functions, and variables. Don't optimize before you have to. Do use version control. Don't generalize until you need to.

See how I talk a good game?

But it's a sham. I've made a mockery of these time-honored rules, and the result is a travesty.

Even knowing these rules, I broke one of them. An important one. One you shouldn't ever break. The one Joel Spolsky calls "the single worst strategic mistake that any software company can make" (www.joelonsoftware.com/articles/fog0000000069.html). That rule, which is so critical I'm devoting a column to telling you about how I broke it and the "traveshamockery" it left me with, is this:

Don't rewrite your code from scratch.

Don't Rewrite Your Code From Scratch

I started rewriting one of my applications from scratch, and it's ruining me. It's making me hate software development. It's making me question everything else I do. It's forcing me to question everything I thought I knew. It's frustrating me so much I don't want to talk about it. And here's the worst part:

It's not done.

Why not?

That's the first lesson behind the "don't rewrite from scratch" rule. Don't do it because it will take longer than you think--much longer. Long enough that it will make you put off other tasks you should be attending to, which you probably should've done prior to, or instead of, any rewriting at all.

In my case, I'm rewriting a nearly 6-year-old web application. I hadn't done much to...

View this article FREE - Now for a Limited Time, try Goliath Business News
Free for 3 Days!