When Do You Retire A Software Application?
There are some obvious signs. Almost all of them are maintenance related. I used the image above because technical debt is what kills us. There are various forms of it, but all technical debt is essentially inefficiency.
What are the obvious signs? Well, if it takes a software developer longer to understand the application than they need to learn modern C++ thoroughly, that's an indication. If the only people who truly understand your software program are people who have worked on it for years, you have an issue. A maintenance issue. A maintainable application is one that can have any developer working on it productively quickly.
If there are less than three people who understand the application, by virtue of long experience, assess your alternatives.
If codebase comprehension becomes difficult, bite the bullet. Fix it, or retire the app. I won't mention the application, but I am working on defect fixes on one right now, which I helped write and fix a decade ago. I can tell from the code comments that once upon a time I worked on this code, and I understood it, but now I don't. It's a hard slog encountering it again. That's a bad sign, when an original coder doesn't quite understand the code that he wrote, and why he did it. It may be a sign of a bad developer - more often it's a sign of bad process and haste. In any case, start thinking of retiring the application.
No business documentation exists as to processes. The application itself is the documentation. Owners (stakeholders, business users, whatever buzzword you choose to use today) rely on the application as being the documentation. Ergo, the application does this, hence that is the business process. Bad mistake. Very bad mistake. In the absence of solid documented and justified business process, you should consider your application to be relatively worthless.
On this one undisclosed application I found half a dozen fundamental defects in less than a month. A junior developer would have located one of them. These defects have existed for over a decade, and they have resulted in permanent damage to data and to maintenance. I would myself rewrite the application, greenfield, and redo business process at the same time.
Document your time. Business owners understand when you say that 75% of your time is spent fixing defects, and 25% is new project work.