I agree with you, and this is a hard lesson to learn. But I don't think it's necessarily a bad thing.
Software should really only be measured by the value it provides. If a terribly buggy piece of poorly written code still saves hundreds of man hours a week, it's a win. (Unit tests be damned)
If that big ball of mud that's using 20 year old technology still prints a billion dollars a year - that's a win. (Microservices be damned)
If some slapdash jquery-and-duct-tape web app still solves a specific problem I have, that's a win. (React SPAs be damned)
Does crappy software flourish while beautiful software dies? Sometimes. But usually code hygiene, security, bug counts and crashes are not what makes or breaks the success of a piece of software. Developers often think their work is the most important, when in actuality it is usually not. Sometimes you really just are a cog in the machine.
Software should really only be measured by the value it provides. If a terribly buggy piece of poorly written code still saves hundreds of man hours a week, it's a win. (Unit tests be damned)
If that big ball of mud that's using 20 year old technology still prints a billion dollars a year - that's a win. (Microservices be damned)
If some slapdash jquery-and-duct-tape web app still solves a specific problem I have, that's a win. (React SPAs be damned)
Does crappy software flourish while beautiful software dies? Sometimes. But usually code hygiene, security, bug counts and crashes are not what makes or breaks the success of a piece of software. Developers often think their work is the most important, when in actuality it is usually not. Sometimes you really just are a cog in the machine.