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.

Lashing

I wouldn't consider refactoring "throwing away", even if not much of the old software remains, after you're done. But no matter what you call it, if it's impossible to manage (and needs to be managed), rebuild it. – Kreit

Check out #1064903 for a similar discussion – Tinctorial

It might be subjective, but it's a real question and it definitely belongs here. +1 from me. – Signification

I think this would fit on programmers.stackexchange.com. – Parenthesis

Look up Netscape Navigator 6 for the scary story. Btw, I've got three boxes filled with 5 1/4 inch floppy disks in my basement. Can't read them, don't want to throw them away. – Valuate

@Hans. It is funny u mention Netscape. In the book "Coders At Work", Joel Zawinski, an original netscape coder, blames the failure of Netscape 4.0+ on bad management decisions. Namely using C++ over C and threading, not the re-write. Joel favors complete re-writes and argues they are less costly than learning a code base and writing new code is "more fun". I respect your point though, but I'm beginning to believe that there's just no right answers when it comes to coding. Or, the right answer is the one that keeps one employed. – Lashing

Jamie, not Joel. Confuzzling. Joel's point is the exact opposite, hard to argue it considering what happened to Netscape. Ultimately it was successful, Firefox does pretty well. Just not for the Netscape investors. – Valuate

Does this answer your question? When to rewrite a code base from scratch – Fadiman

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.

Gasperoni

This is exactly what I am currently doing. As I come to understand the app more I may be able to find the reason for the data integrity issues and save this application...that is if I can survive the facepalms. – Lashing

I've learned that the hard way. Before, I completely refused to use jQuery or any other libraries in my code, as I felt they would be not of my own work. It took me a while to figure out the importance of classes and to reuse those random functions that I conjure up... +1 – Whirlpool

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.

Jarlath

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.

Folacin

The SQL is not parameterized. It's also generated by an in house code generator which ensures the same mistakes are made time and time again. I use the word "data layer" loosely. See Magic pushbutton anti-pattern for an idea of what it really looks like. I completely agree with you in regression issues, that's my biggest concern. The fact that many of the problems are repeated gives me some hope of a true refactor. – Lashing

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.

Survive

Answer 5

I'll make the obligatory plug to check out Working Effectively with Legacy Code by Michael Feathers. He makes a strong case for refactoring incrementally, with a focus on getting legacy code under test. The book is slightly dated, but, then again, so is your code. I found it to be very helpful, as it helped me make a conceptual shift that has changed the way that I approach so-called 'brown field' projects. If a developer is asked to remodel a house, he would rarely suggest bulldozing the structure and starting over from scratch; the project would simply be too expensive and there is too long of a period where the structure is no longer usable.

Gelation

Answer 6

I think software like you describe is not strictly thrown away but may have to be refactored beyond all recognition, probably after first writing a bunch of tests to make sure nothing breaks during the process.

At that point, was it thrown away or not? I would say yes, although the final EXE name and visible operation may be the same. In short, I think this may be more a matter of semantics, and pragmatism in the face of real-world constraints, than actual best practice.

Tracytrade

Thats an interesting way of looking at it. – Lashing

Yes- I am sympathetic to the idea that working bad code is net-net A Good Thing, but at the same time somebody has to maintain it without going insane. Refactoring over time is a way to feel like you are taming the beast, and in the process truly gaining ownership and pride in the program. – Tracytrade

Answer 7

This is exactly the case where you want to keep the old version ;)

Until you replicate the new system with the exact bugs of the old ones, users will demand the old application back... Many users will see some bugs as a feature (like the "quick shutdown option" or whatever quirks you encounter)

Anthropophagite

Answer 8

It's usually very difficult to make a business justification for a complete rewrite when customers are "happy" with a product. My advice is to refactor as you develop new features to slowly move to the desired architecture. This is often easier said than done but, can make sense for projects like you described.

Poise