At my previous company, most engineers and upper management insisted on shipping buggy (95% of tests failed) and badly designed (crashes on bad input, no error reporting) software.<p>All discussions about putting more resources to improve the quality of the product were shutdown by showing either Power Point presentations or emails from our customers mentioning how happy they are with the product.
Here’s the thing about software built for a business: that software exists to serve the business’s bottom line, NOT some abstract ideal of software perfection.<p>Is this example a little egregious? Perhaps.<p>But management has pressures of their own to ship software - many of which are not flexible when quality is at stake, and many of which have hard deadlines. These pressures come from regulators, competitors, investors/the board, or sometimes simply cash flow.<p>And if you want to fix the bugs after shipping, your job is to make a (preferably quantifiable) case for why and how that will be better for the business’s bottom line in the medium to long term than not fixing them.