07.02When to Throw in the Towel - by Dan Goodman
I got an email recently asking for my advice on bug fixing vs. completly rewriting a broken tool. The email described the complexity of the tool in question being caused by the addition of new features on top of an already shakey starting point.
This sort of problem always comes down to time and money. The perception among management may be that this is going to waste time. After all, why rewrite something that seems to work fine, and if there are issues, isn’t it easier (and cheaper) to fix a few bugs than to write something from scratch?
Well, that may be true, but not necessarily. After all, buggy tools waste the time of everyone using them. If ten people waste just ten minutes per day, over the course of a single project that lasts a year, then you’ve lost over 10 weeks worth of work during that project. The actual amount of time may be much greater of course. I’ve worked in some studios where tools were so slow and buggy, it wasn’t uncommon for individuals to lose several hours in a single day.
I knew a programmer who would write almost every piece of code twice. He would completely scrap the first implementation in favor of his second try. The first was basically a learning experience, and once he figured out how to solve the problem, he could do it much more cleanly on the second go.
Rewriting a better tool may be much faster than the initial implementation. The team has learned from their mistakes and may have a much clearer vision for how the tool should be designed and implemented. There may also be some re-usable code, so not everything needs to be wasted; individual modules may be able to be salvaged.
Now comes the real decision point though. Does a rewrite make sense for the current project or should it be put off for a later time? If you’re in beta, rewriting a tool now isn’t going to help you get your game done. Consider how long a rewrite will take in man-days and calender days. If you can get the new and improved tool into the hands of your developers fast enough to save them more time than it took to develop it, then I say, go ahead.
Another aspect of determining when to rewrite is how long it takes to develop code that extends or interfaces with the existing system. If your code is a central aspect of your pipeline and that pipeline will need a great deal of work for your project, there are other gains that you can use to explain why the rewrite is a sound investment.
I could go on and on, this topic reads like my day-to-day experience.
July 2nd, 2009 at 6:35 am
I find a rewrite to be hard to justify unless the code is very immature or incredibly low quality. Mature code includes special cases to fix rare bugs. When rewrites happen, those special cases are usually forgotten, thereby reintroducing the bugs. Also, a rewrite introducing its own new bugs.
Rewrites are also a delay for everyone involved. “If ten people waste just ten minutes per day…you’ve lost over 10 weeks worth of work during that project” Well, if the rewrite takes 4 weeks to finish and is only 50% less buggy then you’ve gained 5 weeks for others but you’ve lost 4 weeks of dev time. Your gain is only 1 week, not 10. (Unless you can write code that’s far superior to what exists already.)
I think about 80% of ‘rewrite’ projects I’ve seen never got finished. It usually comes down to two truisms. Engineers are too optimistic about their skills. Engineers are too negative about the skills of the engineers who wrote the code they have to maintain.
My suggestion: refactor. Treat “bad code” as a bug. Enter it to your bug database, schedule it to be fixed, then fix it not by rewriting but by morphing the code and testing along the way. Often, you can change the architecture of a codebase in-place and fix things without causing a long delay for the rest of the team. Or re-architect to allow you to rewrite a component at a time.
Of course, sometimes a rewrite is still the right choice.
July 2nd, 2009 at 7:16 am
+1 to everything Ted said.
July 6th, 2009 at 6:38 am