[ymerej]

Doesn't it all boil down to economics in the end? When I worked at AOL, QA was very important/valued because our SW was shipped on CDs (I know, I know), and every bug/update cost us users because we had to download an update at modem speed. Now that I work on a web development team, bugs are easily fixed by an update. So who cares if there's a bug? We can just update the site. There are other costs, of course -- if we tolerate lots of bugs and tech debt, making development slower, we will evenually have our lunch eaten -- that's economics too.

Users/customers accept a certain level of quality, and it doesn't make short-term economic sense to provide more.

[ado__dev]

Absolutely. It really is a double-edged sword and there's so many factors that play into.

Do you spend a ton of time writing beautifully optimized code, but ship less features, or do you ship a ton of features that mostly work. I feel like if you take too long to ship, a competitor will eat your lunch. But if everything you ship is trash, then a competitor will also eat your lunch. All about finding that balance I guess.

[strangattractor]

Total agree. There was a time when the deployment cycle was so long it was painful to ship poorly performing buggy software. Now people let their users do the testing.