For OSS projects for example is a lot easier to know when the project dies. When there is no one left to support it, and no one forks it then it dies. It may still work but no one maintains it anymore. You have various insights for projects hosted on GitHub, though you can't solely rely 100% on that.
The project should have tests, of course. A well made software in this day and age should live for at least 3 years without major rewrite. Adding quick fixes diminishes the life expectancy of the software. Adding features with the required amount of refactoring should at least ensure the target expiry date, if not prolong it.
Sometimes we have to rush the project, sometimes we don't know enough about the problem area, or we don't have the resources needed. In these cases the life expectancy is much shorter, because the maintainability costs will either be too high, or a complete rewrite will be needed long before the expiry date.
For OSS projects for example is a lot easier to know when the project dies. When there is no one left to support it, and no one forks it then it dies. It may still work but no one maintains it anymore. You have various insights for projects hosted on GitHub, though you can't solely rely 100% on that.
The project should have tests, of course. A well made software in this day and age should live for at least 3 years without major rewrite. Adding quick fixes diminishes the life expectancy of the software. Adding features with the required amount of refactoring should at least ensure the target expiry date, if not prolong it.
Sometimes we have to rush the project, sometimes we don't know enough about the problem area, or we don't have the resources needed. In these cases the life expectancy is much shorter, because the maintainability costs will either be too high, or a complete rewrite will be needed long before the expiry date.
When I wrote my post I was not thinking about OOS projects at all, I was writing from enterprise closed source code.
Thank you for your contribution to the discussion.