DO NOT REWRITE SOFTWARE FROM SCRATCH!
Today I stumbled upon a GREAT article that I just need to share.
The article is “Things You Should Never Do” by Joel Spolsky.
In case you don’t know Joel Spolsky, he is the founder of stuff like www.trello.com or http://stackoverflow.com and is currently the CEO of Stackoverflow.
He is also the inventor of the “Joel Test” (http://www.joelonsoftware.com/articles/fog0000000043.html) a simple test consisting of 12 Yes/No questions that can determine in a couple of seconds that qualifies how “good” your software team is.
The questions are:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
A score of 12 points is considered “perfect”, 11 is “tolerable” and 10 or less means “you have a serious problem”.
But now back to the article. In the article Joel states that “The single worst strategic mistake is rewriting code from scratch!!”
Let that sink in for a minute. You can rephrase it to “Do not rewrite applications from scratch”. To be honest, I was really surprised to read this line. Especially from a software developers perspective, we generally think that rewriting stuff from scratch is a great idea. Old code is very hard to understand and maintain and nobody wants to do it. Therefore I hear a lot of developers proposing to “rewrite stuff from scratch”. To be honest, I think, I even made this mistake myself in the past.
However, working with my customers in corporate IT I have witnessed the failure of many projects that replaced legacy software by starting on the “green field”.
As of today I have NOT SEEN A SINGLE rewrite from scratch project that could be completed within time and budget. The reasons are obvious. Software matures every year that it runs in production. It is impossible to fully specify a software that has been in production for several years. Most of the time the specification is “it has to work the same way than the old application”. And it is equally impossible to write a test suite that covers every nifty little detail. Joel states that “each of the fixed bugs took weeks if not years of real-world usage to be discovered”. When you throw away code, all the knowledge that went into the code is lost.
The proposal to rewrite software often comes from an attitude that people made mistakes when they wrote it. This is an illusion. It is always easy to criticize stuff in hindsight. That’s why I always base my assumptions on the thought that the people working on the software gave their best. If you encounter a strange piece of code in legacy code, 90% of times there is an important reason why it is there.
Joel proposes that we should resist the temptation of rewriting applications from scratch and focus on making code better. He states that with clever refactoring it is possible to get rid of messy code while at the same time not losing the knowledge in it.
To summarize the article, let me use Joel’s words: “When you start from scratch there is ABSOLUTELY NO REASON to believe that you are going to do a better job than you (or they) did the first time!”
Go ahead, read the article. It could change your career!