When to rewrite a code base from scratch

Question

I think back to Joel Spolsky\'s article about never rewriting code from scratch. To sum up his argument: The code doesn\'t get rusty, and while it may not look pretty afte

Answer 1

I think this depends on two things:

1) How flawed the underlying design of the legacy codebase,

2) The time it would take to do a rewrite.

1) The company I work for used to have a horribly designed codebase, which made the refactor really difficult because we could not refactor one bit at a time, the main problem was not with individual classes and functions but with the overall design. So the refactoring approach, would be very difficult. (If overall design was good, but, say, individual functions were 300 lines long and need breaking up, then refactoring makes sense).

2) Despite a lot code and very convoluted, run processes. Our engine was not doing all that much. So the rewrite was not that long. Sometimes managers don't realize the that functionality of hundreds of thousands of lines of code can be rebuilt in very short time.

We tried to explain this to our CTO (small company), but he still thought rewrite would be to risky, so me and my co-worker rewrote the basic functionality of the engine in about four weekends. Then showed to our CTO and finally was convinced.

Now, if building basic functionality would take us six months we wouldn't have much on a argument.