Whenever I need to make large (laaaarge) changes in code that has been sitting in its place for a while, an exciting and a bit frightening thought enters my mind: "throw it all out and start from scratch". Exciting, because starting to build something that you know is gonna be great simply rocks. Fresh, clean code without months or years of editing history is just lovely to work with. Frightening, because you know how long it took to create the existing code, you know how long other rewrites took to do and you know that this is no exception. Also, you know you are gonna have to address all the problems you had in the first run.
But the feeling that you should start from scratch is always there. In my own forum software, Replique, I already did this twice (although the second was a partial rewrite). With reasons and, fortunately, the desired result: a better application. In a CMS that runs at a website I work for, we also did it twice. And it will probably happen again in a few years.
And this is why. Just this afternoon, I stumbled upon Derek Sivers's weblog, who tried to rewrite a website in Ruby but failed miserably. Rafe Colburn replied to his and linked to a piece by Joel Spolsky, from which I quote:
There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It's harder to read code than to write it.
And that is so true. As is probably true for most developers, my coding style has evolved over the years. Indentation, the placing of braces, the naming of variables and so on, when I look at how I did in a few years ago I scare myself. Did I really write this? Yes I did.
And it's not just the style. Over the years, if you're (aiming to be) a professional developer, you learn more and more new stuff. And every now and then there's the urge to try out those new things. And every now and then one of those urges makes it into your code and stays there for years. When you look at it, years later, you know that you should have resisted the urge. Not that it's bad code, of course not, you're a pro. No, it's just.. silly. The old method of doing whatever it was that that code did was just as good. You didn't keep it simple, stupid. ;)
The Big Question you should ask yourself before starting a rewrite is: am I doing this because I want to, or because the changes I want to make need me to? Is it so damn hard to make the changes in the existing code? Does it hurt to just refactor the bits and pieces you are going to use? Will it hurt the performance when you don't do the rewrite? Okay then, do it. If not: just make the changes and be happy about it not costing you time you could use for really new, fresh projects.
Holy smokes! I had about 30.000 comments waiting for approval on this blog. Most of them spam, according to a quick manual scan. I'm not going to look at 30.000 comments when I know more than 99% of it will be spam, so I logged into MySQL and marked them all as spam. I'm very sorry if this means your comment, which could have been so insightful and very useful to me or other readers, now is gone. Send me a message about it, I can easily restore it.
Oh, and before you mention it: yes, I am going to upgrade this blog and put in a proper spam filter. Not right now, though.
I'll manually check comments more often from now on. So feel free to leave a comment.
I'm working on a piece of PHP-code, and I need to examine if there are any bottlenecks in it. It's not much code, about 170 lines, but there are quite some includes, object instantations, conditions, etcetera, and I can't easily oversee if there's anything that might cause a web server's load to rise too much if this particular piece of code gets executed hundreds of times a second (I know that that is certainly going to happen).
So, what do I do? I do a quick check: do I have any debuggers or profilers running in the background which I can use to learn about this code? And I find there's a Zend Debugger present, because I run a development version of Zend Platform.
Using get_extension_funcs() I know that the debugger has six functions I maybe could use, but I don't know what they do. Can they give me some useful information? I don't know. So I just call the functions to try them out. Nothing of use comes of it. So I decide to look up some documentation on these six functions.
Nothing on PHP.net. Nothing on Zend.com. Nothing on weblogs where Zend Debugger is mentioned. Nothing on forums. Nowhere can I find documentation on how to use Zend Debugger from my code. Doesn't anyone use the debugger? Is it only meant for use in Zend Platform and IDE's like the Eclipse PDT thing?
Does anyone know?