3 ms·
> Quality is expensive. Even a fairly minor improvement in basic Quality can double the cost of implementation. Quality is expensive, but lack of quality is al
by dolni 3y ago
> Quality is expensive. Even a fairly minor improvement in basic Quality can double the cost of implementation.
Quality is expensive, but lack of quality is also expensive.
Low-quality software causes customer churn, increases implementation time for new features, causes more incidents, negatively affects your reputation, etc.
Moving fast is the right thing sometimes. But overall, quality is the way.
- mmcnl 3y agoYou're absolutely right. But if you don't measure churn, time-to-market, incidents, brand reputation, etc., then you will never see the benefits of investing in quality. So it becomes easy not to do it.
- seanmcdirmid 3y ago> Moving fast is the right thing sometimes. But overall, quality is the way. There must be some sweet spot between poor and perfect where (a) the quality is good enough to prevent greater than expected churn and (b) increasing quality anymore is so expensive that the additional profit isn't worth it. When NASA sends a rover to mars, the launch/space travel costs are so high that they can justify investing heavily in quality. That balloons the price of course, and that limits the number of projects they can do. The goal then is to make higher quality cheaper, or to make higher quality unnecessary (e.g. through cheaper launch/space travel costs). I can't imagine it is much different for the software industry (where quality requirements are not as high as aerospace).
- ChrisMarshallNY 3y agoI always think of BMW, as an example of that level. Mercedes is better, but a fair bit more expensive. Bentley, Lamborghini, etc., are inasnely more expensive. Toyota, Honda, etc. are decent quality, though not at the same level, but are a lot cheaper. Of all the companies I mentioned, Toyota probably makes the most money (I have not bothered to check the financials, so I could be wrong). I guess it depends on corporate mission.
- nothercastle 3y agoToyota is the example everyone uses when talking quality. Honda is not far behind but the German brands are far lower quality instead opting for higher complexity. Obviously the Italian brands have never even heard of the word.
- lotsofpulp 3y agoYou and ChrisMarshallNY might be referring to different types of quality. You might be referring to longevity and ease of maintenance quality, and ChrisMarshallNY might be referring to 0 to 60 or some other nebulous driving performance/style/fit and finish related quality. Price/status signaling/size/speed/longevity/etc, lots of different parameters to optimize for and lots of tradeoffs and lots of customers who optimize for different qualities.
- ChrisMarshallNY 3y agoYeah, Quality has multiple axes. For basic dependability, there are a ton of good manufacturers, these days. The whole industry has advanced, quite a ways. But the "fit and finish" Quality (or the car is so fast, you get three speeding tickets when you buy it Quality) are ones that can add serious price to the sticker. I have a few friends that drive BMWs. They are really nice cars, with a lot of things that I consider "frou-frou," but would definitely like, if I had the money they do (so buying a Beemer isn't a big deal to them). They can afford the premium, so they spend it. I worked for one of the top camera manufacturers in the world. Their kit cost a lot more than many, and their main Quality axes were Image Quality, and Dependability. Major-league shooters based their entire [successful] careers on our kit. Their skill was the main determinant, but our kit allowed them to do what they do best. If certain types of Quality are important, then the extra premium is worth it.
- sfn42 3y agoPersonally I think quality is cheaper. Sure, it takes some time to write tests and refactor things when you realize they need refactoring. But those things end up saving much more time than shortcuts that accrue technical debt and only get worse over time.
- ChrisMarshallNY 3y agoI do it, because, every time I count myself, I come up with “1,” so my resources are very limited. I need to keep issue counts in the single digits (with the digit preferably “0”). I use a lot of dependencies, but I wrote most of them. Each is released as a standalone project (usually Swift packages), and testing code usually dwarfs implementation code. I write about my testing approach, here: https://littlegreenviper.com/various/testing-harness-vs-unit/ https://littlegreenviper.com/various/testing-harness-vs-unit...
- Schattenbaer 3y agoPart of this is a problem of quantification and immediacy. Extra time spent doing the work well is easier to quantify as a cost than some issues down the line. Low quality costs money, but only in time, and it's hard to pin down an exact cost. How much of an outage was caused by a quality shortcut? What percentage of our morale issues are caused by working with bad code? And how much, exactly, do those issues cost us? Was some specific quality compromise one of the straws that help break the camel's back? Much harder questions, and the causes are often not clearly linked to their effects. Combine that with the human predilection for shortsightedness and our dislike of delayed gratification and you have a system that is stacked against quality.