[larzang]

Clients don't care about quality, they care about features, so management doesn't care about delivering quality, they care about delivering features, so engineers aren't allocated enough time to care about quality, only features. And then it's still the engineers fault when everything explodes or takes 10x longer than it should to rework or expand a feature later.

Basically it comes down to management that is willing and able to tell a client no, or convince the client to budget to do things right, and not management like my current company, which has in the past threatened to disallow even unit test writing and code review as slowing the process down too much.

"Code quality is time and money you're saving your future self" is an argument that only makes sense to people who write code, apparently, until you actually lose a client to avoidable problems.

[seren]

> Clients don't care about quality, they care about features, so management doesn't care about delivering quality

Up to a point, as soon as you start losing market share to competitors because your customer complains your application crashes every other day. Suddenly, the focus switch back to quality. (Until the next cycle).

What is frustrating as engineer is to release something you know you'll have to fix in 6 months after a customer's complaint. But maybe from a sales point of view that was the right decision.