Engineers aren't blameless, here. In fact they're at least as much the problem as "bad employers". Constantly seeking to use the latest shiny tech toy whether it's appropriate or not (e.g. "Big Data" tools to run stuff on a few GB of data) is a thing, especially in the Bay Area. It leads to a bunch of people with a small amount of shallow experience in a large number of soon-to-be-deprecated technologies. Few want to do the hard work of actual engineering.

Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. So it's not worth it (from the business' perspective) to invest in that quality. Pick some other arbitrary point (e.g. 20% better/20% boost in sales, etc.), right down to some threshold whereby the company simply doesn't even have a product that can be demonstrated.

> Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. So it's not worth it (from the business' perspective) to invest in that quality.

Here is the core of the problem, and it's more of an incompatibility of goals than errors of one of the parties. Businesses want to make money. They usually don't give a flying fuck about what their product is or does beyond the point it gets sold. Does it waste users' time and piss them off? They paid us, which means they value it, so everything is ok.

Engineers, on the other hand, tend to care about what value the product actually provides to their users. So they would rather invest effort in making the product better for the users, instead of making it better for sales team to sell.

I don't really see the way out of this conflict. The engineers are right, but the businesses are right too - it's the business that pays and suffers (some of) the consequences, so it's the business that gets to tell engineers what to do, and not the other way around. If CEO is making a stupid decision, that's on CEO.

The way I see actually useful software gets done, it's outside or on the side of a business, not within it.

Good point about incompatible goals. One way out is to align the value as perceived by users with the value as perceived by engineers. If users aren't willing to pay for reliability/security/etc. then it's rational for management to devalue those properties.

I'm not optimistic that this will happen. Anecdotally, I expound to acquaintances the risks of unprotected PII or questionably-secured home security apps, but convenience seems to outweigh such concerns.

Regulation is one approach to solve asymmetric information transactions. I don't see how that could be applied in general to software quality, but it could target the cases that have severe or widespread effects.

The value the product actually provides to users is the viral coefficient. Lots of companies value growth. Find one.

Growth has been completely gamed already. Just look at most startups.

I agree, but this is essentially a tragedy of the commons problem being exploited by management.

Keeping up with new technologies is essentially a proxy question for, "How much free time do you have that I might exploit later?"

Ok, but his specific complaint was that planning for reasonable failure scenarios makes you labeled not "a team player" or "being negative". And I have seen this happen, it is true problem. Someone else refactoring badly does not cancel that systemic problem out.

>>> Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales.

It's quite common for things to generate or save money. Sadly, most engineers won't bother counting the results related to their work.