Sam Newman has a good article sarcastically depicting why rewriting an application from scratch is rarely a good idea. I share the same sentiment. In fact, I think I'd go so far to say that I would strongly consider leaving a job before participating in a rewrite of an application.
Why? Well for one, rewriting seems like a lot of time and effort to deliver a new product that simply meets the existing functionality of the old one. And it sidesteps the real issue at hand: that the team doesn't know how to care for and improve code as it ages.
The code is difficult to work with because, for some reason or another, it wasn't continuously improved over the life of the application. This might have been due to time constraints, not knowing how to refactor, a lack of discipline to do refactoring, or just a general lack of care for the product. Rewriting the application from scratch doesn't address any of these issues, so you'll eventually have another codebase that's difficult to maintain. Instead, programmers need to commit to the routine cleaning and improvement of the codebase, and management needs to support the programmers' efforts to do so.
In some ways, dealing with an aging, unwieldy codebase is like getting a knot out of a piece of rope. You can cut the knot like Alexander and just do a rewrite, but what happens when you get another knot, which you assuredly will? If you keep cutting, you'll eventually run out of rope. On the other hand, you can gradually pick away at the knot, loosening small bits at a time until larger parts of it start coming undone. And eventually you'll have the knot removed - along with the experience and satisfaction of resolving a difficult problem.
Posts
2 comments: