When rewriting is the “not bad” result
Friday, June 20th, 2008I was reading Don’t be clever and came across this excerpt:
And don’t think that I am saying that there is no place for optimization, that is not true, there is just less room for optimization in the source itself, but there is lots of room for optimizations in terms of overall system performance and in terms of developer productivity. It is more important to focus on the big picture and solve performance problems that are system wide, or refactor code so that changes can be made much faster, than it is to solve a performance problem in a single line of code…unless of course that line of code is being called 8 million times by 50 parts of the system.
So next time you go to write a super clever line of code, think to yourself “Will the benefits of this super cleverness be outweighed by the future issues in maintaining and understanding the code?” And if there is any hesitation at all, then you better not be clever, because 3 months from now you will come across that code and say “What the hell was I thinking?” Then you’ll end up rewriting it anyway.
It’s quite correct, except for one little detail: “Then you’ll end up rewriting it anyway”.
I wish! Doing it right the first time is the good solution, but rewriting it when you latter come across it and realise it’s stupid is a “not good, not bad” solution. The problem is when you just can’t rewrite that piece of crap! Maybe you can’t test it, maybe you have something more important to do, maybe you don’t really understand it, maybe maybe maybe…
I could segway this into the perfect TDD and “Tests as a living, runnable spec” pitch, but I’ll let it rest.