|
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.
|
The problem with throwing away the old code is that you're potentially throwing out the baby with the bathwater. That code could well contain hundred or even thousands of man hours of work. If the tool has been in use for a long time then the code will contain a great many bugfixes, often for wierd edge cases, which you will end up reproducing in the new tool.
It may seem a dismal prospect at first, but if you just steadilly and iteratively apply refactoring then you should rarely need to throw much away. The exception might be where you decide that a platform (e.g. MFC to .Net) or language (C++ to C#) change is required. Even then there are ways to leverage parts of the legacy code so you don't need to rewrite everything.
If you are making a drastic change like 2D -> 3D, then yes, a scratch tool may be in order. But it's not a light decision if you have to open up an empty project file and say, "okay, what now?". If you code something from scratch and look back at your old code to see even 30% overlap, then you've wasted valuable time when you could have just re-factored it.
In my case, getting some avatars moving in the game space was the first iteration. Later, I introduced newly spawned avatars and they needed to be treated differently in code. Many (too many) of my functions had a section to treat legacy avatars, and right alongside it, a section to treat the new ones. Programmers will see where I'm going with this. Eventually, I ran into bugs that either effected one set or another or both. Fixes to one set began to affect the other set. Round and round I go.
I needed to stop that crazy train, after spending a good 10% of my short dev cycle on fixing fixes on things that should have worked if I only had gone one way or another. I really was about to scrap it all and start over, but I stopped and took the time to do a proper analysis on that decision. I took a hard look No development cycle budgets for this kind of analysis, but in the end it was the right thing to do. I soon saw how to untangle the cats cradle I had made (without redoing the whole scheme) and quickly got back on track.
I'm no programmer, but I can see the logic in the case of the programmer who writes everything twice, especially if that work has to be integrated with a team's work. Still, it seemed more important, no matter what the case or how short time is, to stop and do a thorough analysis of the problem of sticking with it and weigh that against rewriting code.