Scrapping It All vs A Salvage Operation

An interesting discussion is going on over at Joel on Software forums.

It all stems from Joel's premise of Don't Rewrite the System from Scratch! He talks extensively about developers' need to develop and not just tweak. This seems accurate because it seems that half the time I look at a block of code, I think “man, this needs to be rewritten”. In fact, I've never known a developer who didn't make significant modifications to a block of code the second they're in charge of it.

Why is this? It's quite simple. Developers think in terms of order and style with their personal style often being mistaken as order. Therefore, when most see a different style, they immediately assume that the code is out of order and work it to fit their order… which is actually just a style.

For example, one of CaseySoftware's current customers (name withheld due to NDA) requires implementing upgrades, support, and maintenance for a major asp-based site. Over the past two years, there have been at least four different developers of at least two different nationalities of at least three different skill levels hacking at a single codebase. Wow. My first impulse when looking at the system was “oh, this is crap. Time to start over.”

Luckily since the site is mostly operational and can handle little downtime, I decided to start by refactoring. After a bit of digging, I found numerous include-files were duplicated verbatim upwards of four times. I found that information such as “Online Status” of users was stored in the database but no garbage collection ever cleared it. I found a network of includes that included other includes that included other includes. I found raw sql in the asp intermixed with obtuse stored procedures and even worse views.

My first step was to start minimizing the duplication between the includes and start breaking them into a simpler set: inc_core, inc_payment, inc_email, and inc_maint with inc_core handling all of the other includes.

Have I completely rewritten some of the code? Yes. Have I scrapped it all? Of course not. Am I done? No way.

So far, after approximately 30 hours of work:
* the codebase has been trimmed by 15%;
* the file count has been trimmed by 5%;
* the “include net” has been trimmed to a depth of 2 from a *known* depth of 5;
* and the database size has been trimmed by nearly 50%.

No profiling has been performed on the before/after response time of the system, but it seems faster.

Now the customer just needs to get their hosting straightened out…

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub