A lot of the time, a lack of bugfixes comes from the incentive structure management has created. Specifically, you rarely get rewarded for fixing things. You get rewarded for shipping new things. In effect, you're punished for fixing things because that's time you're not shipping new things.

Ownership is another one. For example, product teams who are responsible for shipping new things but support for existing things get increasingly pushed onto support teams. This is really a consequence of the same incentive structure.

This is partially why I don't think that all subscription software is bad. The Adobe end of the spectrum is bad. The Jetbrains end is good. There is value in creating good, reliable software. If your only source of revenue is new sales then bugs are even less of a priority until it's so bad it makes your software virtually unusuable. And usually it took a long while to get there with many ignored warnings.

Personally I've never found it a problem to just fix things that I see are broken, as a dev, without PM approval, even in very dysfunctional organizations. Sometimes it even goes noticed and people applaud you for it.

In other words: though I acknowledge that the phenomenon described in the article is real, I sometimes feel it's just because developers accept a reality that doesn't need to be accepted.

This isn't effective at a large org, but if you're running a small company/startup, just have an engineer "help out" with support every so often. We'd ask devs to run the support desk when the person was on vacation and also had a general rotation through.

It's good for building customer empathy but also for helping the people who build the product understand how it's used. The intuition you build up from those experiences is very powerful.

Also, about two hours into handling support tickets for the same issue, 99% of devs will just fix the problem. So you create a very elegant incentive structure for bugfixing that circumvents a lot of the traditional structural issues.

Of course you can't do this in a big company, which is one of the structural disadvantages that come with size.

The solution to this is just build competitors and prey on their market.

It's basically impossible for companies to get managers who can perform at the level required to not end up becoming a blunt instrument "more features now" shitshow.

Just find companies that have reached this stagnant state with deep backlogs, subscribe to their product and study it, rebuild it from scratch the right way, and stick ads on that company name as keyword.

Then when you eventually start strangling them and the MBA simpletons at the top knee jerk with cuts, poach their best staff they didn't cut, and ask them "of those they cut, who would you have kept", and reach out to them.

Basically the only way this situation gets "fixed".

It depends. Some other reasons:

1. It's an enterprise product and the economic buyer doesn't know or care about bugs as much as checklisted features.

2. The company is not connecting the impact of fixing bugs to their bottom line. Or they are and estimate the impact to be low.

3. The code base is due for a rewrite so it would be a waste.

4. It's a side bet not worth the extra resources.