When I first read Joel on "Things You Should Never Do", I thought that though he's mostly right, there are things that can be argued.. It was long ago and forgotten, until recently I've read "Why rewriting code can be startup suicide" article by Steve Blank and it reminded me of that matter. So here are my 2 cents.
In a perfectly designed world—one with no history—we would not have to suffer everything from hemorrhoids to cancer.Neil Shubin
First, let me put some disclaimer. Being a programmer I'm falling under Joel's "fundamental law of programming" that is "It’s harder to read code than to write it." And another thing is that it's kinda hard to argue with two full articles which you mostly (but not totally) agree with.. What I don't agree with is that code "rewrite" being presented as a mistake (even a "single worst strategic mistake") regardless of the situation details.
So when would you consider rewriting? Let's imagine you are working on some project for a time. It should have had some architecture. Which you should have designed based on a TD in a very beginning. If you had a TD. So in the beginning of a project you have thought it all quite well and designed the architecture in such a way that it should be easy to expand and incorporate any bizzare features and requests that can appear during the lifetime. But the truth is that though your architecture is so great, at some point in time you have it so full of things you've added, that your brilliant architecture does not fit them any more.. And you have already used few hacks to fit last 5 features..

There's always a point in the project when you have to make significant changes. The question is how to name it - "refactoring" or "rewriting"? The "rewriting" is blamed for "throwing code away" as if you would erase the "bad" code from your hard drive, your version control, and finally from your brain, to start with the blank sheet. A pretty strange idea actually. But what actually happens is that you just put the code aside and use it as a base and reference to write one that is better. If you call this "refactoring", then, I believe, nobody sane would do what you call "rewriting".
For me, the difference between refactoring and rewriting is that when you refactor you do consequent changes in some module while keeping a whole system compiling and working as before. And it's what you should do most of the time. But sometimes the changes to be done are so huge that it's much easier to write the module "from scratch" than to evolve it. And it would take less time as well. Once again, it does not mean that you would throw away all the work that you and others did before...

As a conclusion.. Every method has its place. Refactoring is your main tool, but sometimes it's really more useful to rewrite part of code than to refactor it. Just try to consider all pros and cons before making a choice.

There are too many programs that should be better than they are now, including huge and widely-spread commercial products.. I wonder, if developers would use rewrite a bit more often and bit more wisely, maybe we'll be living in a better world..
No comments:
Post a Comment