Never throw software away?

Question

Is it never ok to throw out software?
Joel concludes companies should never toss out software.

I try to be a good little programmer and follow this rule. I've come into a five year old project that's been run by one man. It is filled with anti-patterns and generally of poor design. Most of the problems are from the data layer with inline-dynamic SQL.

• Pro's: Users are familiar with the way this app works and comfortable with it's bugs. Requirements are built out, but there are some underlying issues which have caused users to question the overall reliability of the application.
• Con's: Anti-patterns, intense coupling, inline SQL, impossible data layer.

I could re-gather requirements and build using OO, design patterns, and modern .NET techniques to make this app. manageable and teamable.
In small applications, with problems such as these should we follow Joel's advice?

This question may be thrown out for being subjective, but I find this to be of critical importance to my job as a programmer.

Answer 1

What Joel is getting at is that if you throw everything out and start from scratch, you are throwing out years of work without any guarantee that the rewrite will be significantly better than what you already have.

Instead of focusing on a rewrite, consider the practicality of refactoring one piece of your application at a time. Instead of inline SQL, perhaps think about creating a new data layer, perhaps based on a "better" approach such as LINQ. Then you could migrate over to that new layer one function at a time. In this manner you will move forward towards your goal of a better code base, without having to throw away years of previous work.

Answer 2

My advice would be this. If it works, don't mess with it, until the next significant release in your application. Then refactor as you deem necessary. We face that same thing at my company, and we typically handle the problem the way I described.

Not throwing away old code, or bad code, or no longer relevant code, is, IMO, ridiculous. Unless the code has key pieces that simply cannot be easily reproduced.

Answer 3

Most of the problems are from the data layer with inline-dynamic SQL.

As long as there is some distinction between UI and data, this isn't necessarily a problem. Don't prejudice inline SQL - as long as it is parameterized, it is a perfectly workable approach.

Re the question; I would question what the technical reason for scrapping it is. If you can justify it in real terms (ideally in $£€¥), then great. But don't do it just because you don't like the look of it. I've scrapped code before, but trying to do it in a regression-free way can be tortuous.

As for the users; done right, they don't really need to know that there is a change, but even if you want to change the UI - most people are pretty flexible and are happy to adapt to a new UI.

Answer 4

Rather than throw everything out and start from scratch I'd refactor it as I go, making small changes supported by unit tests. The cost of re-writing it from scratch is rarely worth it.