The urge to rewrite software

Having previously been a programmer myself, I can attest to very real and maddening phenomenon that affects nearly everyone in this line of work: the urge to rewrite. It comes on hard and fast, usually immediately after finishing a piece of software. Sometimes it even comes on smack in the middle of your efforts.

The reason is simple: as you go through the process of writing the code, you gain new perspectives on the shortcomings of your original approach to the problem. It’s the same thing that happens when we look back on the events of our past and think “if I only knew then what I know now…” In a way, the better the software that you’ve written turned out, the better your perspective becomes, and therefore the more pernicious the urge to rewrite it becomes.

Maybe no one would notice if I started over...

A great example of this is our own Knowledge Management software. It’s a great piece of software that’s very highly regarded in the industry, and an awful lot of people tell us how much they enjoy using it. We could very easily add on to the existing code base, adding new features and improving existing ones, and release a new version and make a ton of money. But it wouldn’t be as good as we know that we could make it. Because now we’ve been working with the product for years, supporting it, using it on our own site; we know too much about it now; we know what its potential is.

So what are we doing now? Rewriting the whole damn thing from scratch. And it’s going to be great. It’ll be a lot faster, more flexible, and have lots of little touches that would’ve been too difficult to work into the old framework.

Of course, like anything, there has to be balance. You can’t rewrite a product every day or even every year and still remain profitable. At some point you have to recognize that no matter how much potential you see, only a certain amount of that potential is realizable in the immediate future. No matter how good a piece of web software becomes, there will always be room for improvement. The better a piece of software gets, in fact, the more strongly it advocates for the shifting of its own paradigm. You’re always climbing into view of the next incredible set of previously unthinkable goals.

The art of software development is in recognizing when you’ve found a nice plateau, and then allowing yourself to rest there for a while. That way you have room for some horizontal growth–feature enhancements, optimizations–and this give you and your clients time to enjoy all the hard work and creativity that’s gone into the software’s current iteration.

A trial is worth a thousand words.
Get started today, no credit card required.

 
 
  • As a developer myself, I find myself rewriting code on a whim as well. Usually though there are only so many times you can do that before you end up with too much feature creep or you end up with something that was better in previous versions. Projects vary and sometimes you can easily rewrite a header or something. I find most code I write is nice to have in a modular format. IE UI handled only 1 one way then functions and classes handled another. Combine effective version control techniques and good programming practices and even a newer development can stay above the water level. Nothing worse than rewriting on a dead line!

    I know this is probably a stumble upon ad. However there defiantly are tips to keep your productivity up and having the ability to merge only the best iterations of your code!

  • Peter

    I notice our design patterns change sometimes; what once seemed like a good idea now no longer does. It’s about that time when a rewrite rears its head, and generally for good reason. Once you’ve moved past a certain idea, it becomes hard to design with it. So you set about changing it, and then, well, you figure you might as well change it everywhere.

  • Thanks very much for your comment, Greg. I definitely agree that rewrites should be kept to a minimum, otherwise nothing will ever be finished! You have to come to a point where what you have done is good enough, even though it will never be perfect.

    But I think there is also a lot of value in knowing when the investment in re-writing will result in enough improvement to be worth it. Like Peter says, it amounts to feeling out whether you have reached critical mass in terms of moving beyond the original guiding principles of the project.

  • Mike

    I consider re-writing software (a.k.a. refactoring) as the equivalent of simplifying equations in mathematics. IMHO, those who don’t habitually refactor will never produce great software.

    For years I’ve been using the fantastic IntelliJ IDEA IDE, which makes refactoring much less time consuming.

    • “I consider re-writing software (a.k.a. refactoring) as the equivalent of simplifying equations in mathematics”

      I think that is a great way to put it.. Software must evolve over time. The trick is maintaining a balance with getting results and continual refactoring.