In a now famous article by Joel Spolsky, he argues that you should never rewrite projects from scratch. To be fair, I’ve done this, but generally on open-source projects where I’m donating my time. I’m less worried about financial constraints or competitive advantage.
Aside from that edge case, I generally agree with Joel Spolsky. If something is a tiny project, refactoring is often trivial and if you want to do a rewrite, so be it. However, large projects are often dangerous to rewrite. But how did they become large projects? The vast majority of “large” projects I have worked on started out as small projects which gradually had features and cruft added. Interestingly, this is very similar to how agile methodologies work: build something small, but useful, in the first iteration or two. Always have working code and keep building on it. So the rewrite seems like a good idea because we’ve already shown we can create the project, right?
Anyone familiar with the Mythical Man Month has an idea of how and why large projects are more likely to fail than small ones. When we have a rewrite that we’re concerned about, we tend to have a “large project” and thus we increase its chance of failure. However, we also have a lot of domain knowledge and if you have competent enough programmers with plenty of experience, is this domain knowledge sufficient to overcome the disadvantages of a rewrite? The larger the project, the more likely the answer is “no”. However, while I’ve seen plenty of studies regarding the success of projects and correlating their success with project size, I can’t recall seeing one correlating success with whether or not the project is a rewrite. Though this is informal, what’s been your experience? I don’t expect you to answer all of these questions, but I’m curious.
- What was the problem domain?
- Did the project succeed or fail?
- What success criteria were used to judge?
- What was the rationale for the rewrite?
- How many developers?
- What was the “size” of the project? (tough to quantify, I know)
- What was the expected versus actual timeframe?
- Was automated testing involved?
- Any other comments you care to offer?
Feel free to answer any or all of the questions above.
I hope Joel is wrong because that is what we are about to undertake at work.
I'm in the middle of such an endeavor right now. The project began because the current application is an unmaintainable mess written in spaghetti ASP code. We're moving to the more maintainable MVC architecture of Ruby On Rails. Sadly, I'm the only developer on the project. There should be two, but circumstances are preventing this which I can't discuss. Currently the project is around 2400 lines of code with a 1:1.5 production code to test code ratio.
This was my first major project, and I've learned a lot in the process. The most important thing I've learned is the value of having a test version of the application. I've not had this luxury, and probably won't, until the project is almost complete (for a variety of reasons I can't get into). But boy do I wish I did! Employers get awful antsy when they can't really see what you're doing.
It seems that non-technical employers assume we are all alchemists capable of conjuring their dreams into gold with a few keystrokes. You have to learn how to say "no". You need to learn how to look at the existing version of the project and tell them why some features need to be chopped out and why some of their plans for the new project won't work. But hardest of all, you need to learn how to keep your cool when they get frustrated, upset and angry.
I have to say that it depends on how similar the original project is to the new project.
At my company we have done it both ways on large projects. We run an e-commerce web site and a couple years ago decided to rework the checkout project. For this we were going from a PHP 4 convoluted procedural set of programs to a (IMO) cleaner PHP 5 OO process. For this we did a (near) total rewrite, mostly using the old project only for the basis for some SQL queries.
A more recent update to the site involved the user's browsing experience. For this we mostly used the old functions, refactored for performance.
Both of these projects involved a comparable depth of code and took similar amounts of time (the second one had a few more new features, and so took a couple extra weeks). The code for the second project was much cleaner and better organized to begin with and so much closer to the final product we wanted so it made more sense to work from that base, rather than a full rewrite. Blanket statements like the "rewrites are always bad" are rarely 100% accurate, it almost always depends on what you have to work with to start with.
I worked the 3D package Maya for about 13 years. It was a rewrite of PowerAnimator consisting of millions of lines of code.
Today Maya is very successful and well established. But, at the time, it was a very painful process. it was released years past the original deadline with dozens of extra developers added to rush it out. When it was released, it was feature incomplete and contained more than a few bugs. It didn't really hit its stride until v2.5. It almost killed the company...then SoftImage did the same thing right after and it almost killed them too.
It took years to build Maya's customer base up to what PowerAnimator had.
Could we have refactored PowerAnimator instead? I suspect that we could have given that the StudioTools team did it and they still have a very successful product.
Deciding whether to rewrite is hard. I think Maya is a great product, but if I had it to do over now, I would probably side with Joel on this one, at least for huge client-side applications.
My advice would be to write loads of tests so that you can refactor with confidence when the time comes to freshen the architecture...
I say Go Ahead, Do the Big Rewrite.
The best advice I heard was "write to throw one away". Do a from-scratch rewrite for any major project, but do it EARLY. i.e. don't let your beta be your alpha+1, write the beta without making known mistakes, rather than trying to retrofit better snippets into alpha.
I did maintenance on existing versions of a TCP/IP stack for IBM mainframes while the lower levels were written from scratch. The original product was public domain code from a university and had become the proverbial rat's nest. The project took about 1 year, and I would call it a success based on the following:
1) The new code worked a lot better
2) The changes to existing customer configurations were minor and a conversion tool was provided
3) The new code added some features, such as support for more concurrent connections, which justified customer upgrades
I did not work on the development team (4 or 5 people), but supported the existing code base, which I think underlines the point that there is a lot more to it than just writing new code. I had been pushing for better training for our help desk staff to reduce the number of trouble tickets that were forwarded to software maintenance, and the rewrite helped me get my wish. I started a weekly lunchtime conference call where people would sit at their desk and view config/log files for a specific topic, while I explained them and answered questions.
I did not collect hard stats, but the feedback was very positive, and my gut feeling was that I worked on fewer 'trivial' problems. Also, when the new version was released we had a procedure in place for getting people up to speed on it. From this experience and similar ones at other companies, I'd say that the more involvement from everyone in the organization on preparing for the project, the better your chances of it being successful.
Later . . . Jim
RenaissanceCore IDS, check it out at:
http://sourceforge.net/projects/renaissancecore
I'm surprised no one made the economic argument yet: you tend to see a better return on the investment in creating software the sooner you release that software, so much so that there's a strong correlation between the value of a feature and the money you make back from releasing that feature to customers.
I read Joel's argument as saying that if you stop releasing software while you try to get a completely new project back up to the point of value, you take value away from your customers.
Some important factors are how long ago the development was done, how competent the developers were, how much the requirements have changed since, and how well the developers documented their design and commented their key code decisions.
But the most important question is, Why has the question of whether or not to rewrite a project come up! What does the customer (who may be yourself) want you to do with/to it? Extend its functionality? Make it more portable? Improve performance? Make the infrastructure pluggable? Those scenarios, and the factors I listed in the first paragraph, have such a large effect on the question of whether or not to rewrite, that to make a blanket assertion is ludicrous.
My personal experience has been, for the most part, that rewrites were more effective. In general, I was assuming responsibility for code that required relatively minor changes but which I needed also to be familiar with so that I could quickly respond to failures caused by a changing environment and - most importantly - fix obscure bugs.
Recent case in point: I was asked to take over a metrics application written three years earlier by someone who had left. Perl and databases were not their forte'. Neither was documentation (as in, none.) I needed to change the source and target of the data and fix some problems, plus educate another developer on the code at the same time so we hadn't just replaced a single point of failure with another one.
The main part of the code that I needed to attack was 2800 lines of Perl. The requirements for the task were not documented at all. There were no tests. The customer was too busy to be involved. The code was full of duplication and there were about three subroutines in the whole thing. Not only did I have to rewrite it from scratch, I had to reverse engineer the requirements from the existing code while figuring which parts of the behavor were actually bugs. By the time I was done it was under 600 lines plus POD. The other developer watched as I repeatedly applied 'Extract Subroutine' to shorten the code and attach meaning. If I had had even reasonably complete requirements to begin with it would have been far faster, because it turned out not to be a terribly difficult task, but understanding how it was supposed to interact with the outside world was quite the spelunking task.