Don’t write from scratch
It’s several years now that I am out of school. I have a BS in software engineering and run my own company. I was taught stuff about compilers, queues, patterns, languages, mathematics, datastructures, … you name it. Asked what I was not learned in school I would answer: “how to fight the urge to rewrite everything”.
To a die hard software writer “rewrite it” seems like the perfect solution to every problem. The silver bullet to all failures in IT. After all the others are just a bunch of loosers losers and I am Mr. Super-Design-Software-Pattern-On-The-Edge-Flavour-Of-The-Day-Framework-User. Just tear everything down and start from scratch. WRONG. WRONG. WRONG. Whenever you have to touch a software system, be it for enhancements or for fixing bugs, and you feel like you should dump the whole codebase and just start from scratch (after all it’s so easy to do it. It probably takes 3 days) step back and take a deep breath. The authors of this system were not just a bunch of idiots. They had reasons to do it the way they did:
- The business is not as easy as you might think at a first glance
- Technical restrictions from inside or outside
- The system evolved over time
- Your state of the art framework/programming language/tool was not available when the system was written
- They knew less than you know now (unlikely…)
So think twice. And then think again. Wouldn’t a tiny update or bug fix do ? You need to add new features and the original system was written in Cobol/Fortran/Delphi and you do not have a clue of these languages ? Perhaps you can add the new stuff with your super-duper framework/language and just integrate it. Find someone who knows the language, chances are hiring someone is less expensive as you rewriting the whole system.Yes. This is something I was not taught in school. This was something I had to find out for myself. I made my own errors … not that i tried to write Mozilla from scratch… it was on a smaller project. Lessons learned!
Resources: Years ago I read an article on this topic. I think it was it in Joel’s book ? Anyway. Here it is: Things you should never do, Part 1
back
July 16th, 2008 at 14:26
I’m sorry to be a nazi and I would have emailed this rather than posting normally, but could you please correct your spelling on “losers?” Lately I’ve seen this misspelled so many times it’s driving me up the wall.
Other than that you make a very excellent point. That’s the problem in general with CS degrees - they concentrate on so much of the technical aspect and exactly zero of the social / interactive aspect of software design / implementation. I’ve worked for several companies in the industry now, and so far there hasn’t been a single one where I can just go code in a black hole. Even if you’re the ONLY dev on the project you still have to interact with clients, managers, etc. It’s a shame schools overlook that entire skillset.
July 16th, 2008 at 14:44
Sometimes an entire rewrite makes sense, sometimes it doesn’t. You can’t give a better answer than that unless you’re in the context of a specific problem.
It all comes down to time. A rewrite has a huge up-front cost, but updates will take less time. Keeping the old code has no up-front cost, but updates take longer. Which options is better? It depends on how bad the old codebase is and how many updates you will need to make. Without knowing the specifics of the situation, its impossible to say that a rewrite is the right or wrong way to go.
July 16th, 2008 at 15:05
Where is refactor? Also, you have probably only worked at places that had some sort of standards. Ever seen a 5000 line script without a function where the programmer relied on a run time error to stop a loop because “it worked”. Seriously … some code is begging for a refactoring. As you did not mention it I wonder if you equate refactor with rewrite.
July 16th, 2008 at 16:10
I agree more or less except for one important part:
“The system evolved over time”
THIS, and it is my serious experience, can REALLY become bad.
Sometimes solutions are not clear exactly because they evolved slowly.
Evolving often means that things go the fastest route to success but not
always is this the SHORTEST or BEST route.
July 16th, 2008 at 16:44
Sometimes you find that it’s easier to start from scratch than fix all of the bugs. When the old developers obviously didn’t know what they were doing when the system was created 6 years ago, I think it’s ok to rm -rf * and start over :)
July 16th, 2008 at 17:56
There are some cases where a rewrite would have been profitable in the long-term. The best example is Twitter. The initial codebase was not meant to be what Twitter is right now. Instead of just rewrite the application, they streched the initial architecture up to its limits and now they struggle. They finally decided to rewrite it from scratch.
July 16th, 2008 at 20:28
Pheu, I can assure you that Joel learned things the same way we all do, the hard way. So unless anybody who reads this post will mist few deadlines because rewriting is soooo cool, he won’t understand a word from what you are saying.
Actually I’m fine with this, I do rewrite a lot. Not everybody likes me as you can imagine =]].
July 17th, 2008 at 0:04
“What’s a looser?”, she said. “Is it someone who sets things free, or unbinds things?”
“Loose the Dogs of War”, he said.
“Did you ‘lose’ your car keys, you ‘loser’?”
“I swear to God, I’m losing my mind!”, said the loser.
Well, you get the idea.
July 17th, 2008 at 3:40
Please stop perpetuating this received wisdom. Many of the people that believe rewrites are always bad, have been blessed to work in places where, while the code might be ugly, isn’t hopelessly unusable. Joel would fall into this category, in fact Joel does not have a wide breadth of experience in the different and typically cost focused working environments that face most programmers.
A lot of the antipathy towards rewrites comes from situations where a team produces a project that sucks, they then recognize it sucks and then attempt a rewrite. Personally I think this is a waste of time because you’re not going to get a better result the second time around if you didn’t have the smarts and experience to build it in a more ‘refactorable’ way initially.
I have been involved in many successful rewrites that solved many problems and ultimately saved a lot of money. Rewrites are not evil, stupid programmers are.
July 17th, 2008 at 9:43
Delphi in the same breath as Cobol and Fortran! Oh dear! FWIW, I work for CodeGear (now part of Embarcadero) on the Delphi compiler, and ironically enough, it’s one of those C programs that has you itching to rewrite. I had a longer comment, but I moved it on my blog, as it was getting big…
July 25th, 2008 at 17:08
Thanks to all those readers pointing out what a looser/loser i am. I’ll invest my next salary in a spellchecker :-).
And thanks for reading.
August 13th, 2008 at 18:02
I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!