It seems software very quickly and perhaps undeservingly gets labeled as legacy whenever it doesn't use the latest version of your favorite technology, the people that implemented it have moved on to better things, or if it has been in maintenance mode a bit too long.
I'm glad this doesn't ring true for everything in life. In some professions people actually prefer the old. Car mechanics need to know the ins and outs of legacy and new cars alike. I guess the thing you have experience with is typically easier and more fun to work on. It might be muscle memory, or the fact that it doesnt hurt as much... Wait, what? Hurt? Well, yeah, as the saying goes: if it hurts, do it more often. Well, they did it more often, and as a result they prefer what they know.
That worked out great for me back when I was driving around in my used Ford. My mechanic could usually tell what was up with the car even before I came in.
Imagine, for a moment, what it would be like if they were more like us. You would come in with your car, they would pop the hood and start up a rant about how all the problems you are having are related to its antiquated electricals, and then urges you to talk to the salesperson about buying a new one. I guess this would be the reverse of "They don't build 'm like they used to".
Since the software field is still relatively new, it makes sense that the technology and our understanding of the craft constantly evolves. Maybe we need to give our past selves some slack: we did the best job we could or knew how. Come to think of it, realize that the software we're building today is doomed to become legacy sooner or later, with all the bad properties legacy seems to have. By then we might have evolved to other practices, or using a language at a higher level of abstraction.
I really like Joel Spolsky's blog. I followed it religiously for many years, and one of his posts is a great intermezzo for this little topic: "Things You Should Never Do, Part I"
So what are these legitimate reasons I speak of, you ask? The usual situation is when you have a monolithic codebase, with business logic, data access, presentation and behavior scattered randomly throughout. Where only a handful of people, diminishing over the years, know their way around the code. Some of the readers have now undoubtably had flashes from past projects where one or more of these malpractices were employed. However, I would like to argue that, even with all of these reasons, I don't feel this is enough to warrant the rewrite.
As long as you can afford to hire people with the right skillset, the odds should be in favor of remaining in maintenance mode. Their prices may rise over time - as less people have the required skills - but for the right price you will undoubtably find candidates.
Only if you project that the cost of keeping the product in maintenance exceeds the cost of redeveloping it, it might indeed be a good time to start planning.
