4 ms·

Refactoring takes time, expense, and expertise. Keeping legacy applications running as-is takes 'merely' documentation and a sense of pragmatism. I submit that

Refactoring takes time, expense, and expertise. Keeping legacy applications running as-is takes 'merely' documentation and a sense of pragmatism. I submit that the best approach for dealing with a legacy application is to Leave It The Fuck Alone. (LITFA) Don't extend them. Don't try to understand their inner workings any more than you have to to meet business needs. Just Don't. Leave it the fuck alone. You can keep them running a long long time, generating revenue, while you plan out replacement greenfield apps for the time when you really honestly do need them. If you have a problem with it, fix it and document the solution. It will happen again. Put a little extra time in and fix it a little better this time, updating the documentation. Over time you will come to understand its behavior. Under no circumstances make any major changes to it. Keep everything tiny and fix exactly one thing at a time. Refactoring legacy apps is good in one and only one situation, you've got massive amounts of money riding on it, enough so that it's worth doing everything right.

user5994461 10y ago
Need a book and a design pattern name for that. It will make it easier to sell to management and to train new employees about.
- vinceguidry 10y ago
  If anyone wants to offer me a book deal and reserve, I'd be happy to write it. Though honestly I think the best path forward is to start a company offering fixed-price legacy app maintenance. Another thing I'd consider doing if I got the right offer.
  - toomuchtodo 10y ago
    > Though honestly I think the best path forward is to start a company offering fixed-price legacy app maintenance. So a dog and a human? A human to watch the legacy app, and the dog to bite the human if they try to touch the legacy app.
no_protocol 10y ago
> Just Don't. Leave it the fuck alone. Reminds me of a passage from "Working Effectively With Legacy Code" by Michael Feathers. The book is about dealing with those times when you absolutely must make changes to that old system. This is from the end of Chapter 1: It's tempting to think that we can minimize software problems by avoiding them, but, unfortunately, it always catches up with us...In poorly structured code, the move from figuring things out to making changes feels like jumping off a cliff to avoid a tiger. You hesitate and hesitate. "Am I ready to do it? Well, I guess I have to."

user5994461 10y ago

Need a book and a design pattern name for that. It will make it easier to sell to management and to train new employees about.

vinceguidry 10y ago
If anyone wants to offer me a book deal and reserve, I'd be happy to write it. Though honestly I think the best path forward is to start a company offering fixed-price legacy app maintenance. Another thing I'd consider doing if I got the right offer.
- toomuchtodo 10y ago
  > Though honestly I think the best path forward is to start a company offering fixed-price legacy app maintenance. So a dog and a human? A human to watch the legacy app, and the dog to bite the human if they try to touch the legacy app.

no_protocol 10y ago

> Just Don't. Leave it the fuck alone. Reminds me of a passage from "Working Effectively With Legacy Code" by Michael Feathers. The book is about dealing with those times when you absolutely must make changes to that old system. This is from the end of Chapter 1: It's tempting to think that we can minimize software problems by avoiding them, but, unfortunately, it always catches up with us...In poorly structured code, the move from figuring things out to making changes feels like jumping off a cliff to avoid a tiger. You hesitate and hesitate. "Am I ready to do it? Well, I guess I have to."