Code Extinction

for RuBoard

Naturally, there are times when code simply cannot be evolved, times when it needs to be discarded and started over. In nature, we call this extinction, and if you've coded for very long, I'm sure you've seen code that really needed to go the way of the dinosaurs. I once had the misfortune of having to work on a financial software package for a Wall Street-based technology company. The GUI portion of this code was so poorly thrown together that I would find myself looking for ways to get out of even going into the office. It was one of the worst messes I'd ever seen. The original developers thought it was more important to cobble something together quickly in order to impress the nontechnical folk in the company (who didn't know any better), than to improve their education and skills as coders, to learn how to use their tools properly before billing people for it, and to build something that developers down the road ( themselves included) could venture into without stepping on a landmine. That code needed to go awayvery badly .

In such cases, it's often better to start anew. One sure indicator that it's time to discard a project and start from scratch is when the software simply doesn't work. At all. If it's infested with bugs inside and out, gradually reshaping it may not be possible. You can't build a house on a rotten foundation or add onto a building that's infested with termites. Conventional wisdom says you should probably just tear it down and start over. Remember, the refactoring game requires you to preserve the functionality of the system while improving it internally. Preserving functionality is kind of tough when the app isn't functional. You may be better off starting over. Some software is so poorly constructed that there's just no other way.

Even when you decide to rebuild, work on small pieces at a time, gradually evolving your new creation until it has the functionality you need. Strong componentization and encapsulation may allow you to make the refactor-versus-rewrite decision on a module-by-module basis. ^[20] When you do opt to rewrite, change-test, change-test, change-test. Eventually the new effort will either begin to resemble what you and your users envision, or you'll discard it and start fresh. Of course, you don't want to discard an effort prematurely or reject it because you don't understand it because you haven't made an honest effort to understand it. Too many wasted efforts, and you may find yourself on the brink of extinction. Management tends to frown on tossing out work for which it has already paid. The judgment to know "when to hold 'em and when to fold 'em" comes with years of experience. No book, including this one, can tell you exactly when it's time to pull the plug or to press on. That's an exercise best left to the reader.

^[20] Ibid. Page 66.

for RuBoard