I remember reading an article over 10 years ago on TheDailyWTF, where Alex Papadimoulis was sharing something, that made quite and impression to me - our industry is failing to recognise the failure. We usually declare a project successful when we deliver it and get paid for it. However what we do is similar to building machines. Take cars for example - they are built to last and to be safe. Two aspects we sort of neglect when building software. I know we try, but compared to the car industry - our attempts are such a joke.
What Alex said in the article was, that a project can be considered if people still use it decades later. And if not - we should be rather consider this project a failure, not anything else. Take for example Windows XP - people loved it and used as long as they could. Some systems, written in COBOL, that sadly are still in use are older than me and I don't think anyone can say, that I'm young with all my gray hair. These systems are a massive success.
Note, that I'm not saying, that these systems never got patched or modified in any way. A successful project evolves over the years and people keep maintaining and enhancing it, but in it's roots it's the same project, based on the original design and architecture.
I'm not sure all projects are meant to live a decade or more. I think a better metric is whether you can patch/update a project over its lifetime (whatever that is) without costs skyrocketing or without having that "oh crap, all the original developers have left the team so now no one knows the code anymore!" moments.
Sadly, what I have noticed is that everyone knows how to write good code, everyone can criticize for hours past projects they have worked on on how poorly written the code was, yet when push comes to shove the first thing that get thrown under the bus is quality.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.