Rewriting software from scratch
A co-worker of mine today sent me a link to one of Joel Spolsky’s older articles entitled "Things You Should Never Do, Part I". Joel hits on a lot of points in the article, but the basic premise is that you shouldn’t rewrite software completely from scratch, but rather you should incrementally improve it over time through refactoring. In fact, he considers a complete rewrite the "single worst strategic mistake a company can make".
I agree to some extent, but I do believe there is the rare time when a rewrite is necessary: major technology changes and major methodology changes. This isn’t exactly a good position for a company to be in. In fact, I think a company is risking its future if it isn’t keeping its technology up to par and ensuring that its philosophy to software design is meeting its needs.
Major technology and methodology changes become necessary when a company wants to stay competitive but has done a poor job of refactoring or improving its product fast enough to keep up with the market’s changes in technology and product cycle times. Like I said, this is a bad position for a company to be in. Constant and iterative change must be a basic operating principle of an innovative and successful company, so if a company is not doing this then shame on them.
Filed under: Software
One of the problems a company can run into is a large application with a large install base of users who aren’t primarily computer people. The product I work on has been dragged through several platforms and never really given the opportunity to be “actually” refactored and brought up to the state of the art. I’ve looked at C code that is 14 years old and more. Much of the time, the “if it ain’t broke don’t fix it” approach has ruled the day. Recently, there has been a big reduction in force that will force those of us who are remaining to reverse engineer and refactor the system into something new (the thing was aging horribly anyway). The product is basically the poster child for why iterative and keeping things current is a good thing.
But, I must temper this with the tendency of the company tending to shift focus around without giving extra time to make up for the loss of productivity, which is how the product got to where it is in the first place. I reckon this is just one of the many issues with being profit and growth driven.
Anyway, nice to see you are still around somewhere, kev.
Thanks, Ernie (or do you prefer Ernest these days?). It’s good to know you’re out there and still digging into software.
I agree with your statement. It seems like a lot of companies have difficulty balancing between short-term and long-term goals, even though that balance is key to long-term success. From a software engineering standpoint, refactoring is one of those activities that helps long-term goals, but it seems that management in some companies does not recognize that refactoring is investment in the long-term.