Quality has to be backed my metrics or else it will never happen. PS. Big fan of this person’s recent blog posts. He’s been on a roll!
It used to happen because people believed it was simply the right thing to do.
Quality is a hard sell in big tech
121–130 of 165 posts
Re: Quality is a hard sell in big tech
#122Earlier quoted context omitted.
I’m glad i’m not the only one that sees this. Often I read an article and that ‘word’ pops up and the article loses credibility, because of this ‘technobabble’ which is worse with purposefully laced vulgarity. It’s always used in tech circles because it’s ‘funny’ now but we know we cannot say this in a serious discussion in public or context and expecting the other side to take what you’re saying seriously. You are r…
I'm kind of sad to see this reaction, because to me the vulgar part isn't what's objectionable about it, but I can't stand the awkward madeupness of the word. "Shittification" would have been bad enough, but the "en-" just makes it cringe.
I think that’s just you. The word formation made perfect sense to me the first time I read it.
Re: Quality is a hard sell in big tech
#123Earlier quoted context omitted.
Yeah sure, really expensive until the accumulated tech debt prevents any productive work from being done. Correct a typo? Sorry boss, takes at least 1 year, shit hits the fan when you change labels like that (the truth). How much is your salary? Oh ok... let's not do that then. Managers throw more people at the problem to improve productivity, only for the new people to need training. Okay, let's have the new people…
Then they drop project and start new one. Software is not endangered species to protect it by all means. When I am done with my car I just get a new one. Yes there are software projects that need high quality but it is not 90% of cases.
I think cars are a poor example. Cheaping out on quality can cost companies 6 years of 12 developers' salaries, market share, reputation, customers and bankruptcy procedures instead of... 3 years of 9 developers' salaries.
I've seen it firsthand: Major update to our only software product. Years of work. Everything is moving too slow. Managers hire more people. Performance tanks due to training the new folks. Our publicly available software is abandonware, all hands on the major update to get it done. A few customers switch to competitors, but hype is high for the new update.
After 5 total rewrites, they cut their losses and launch the half-baked current iteration. Launch feels earth shatteringly disappointing and insulting to all stakeholders, even including the developers of the major update. Developers receive death threats. Many developers leave the company. Remaining customers flee to competitors.
Lessons learned: Don't cheap out on quality. It can quite literally cost you your company. Nobody needs absolute quality, and that's impossible to achieve, but at least try to care about quality.
Re: Quality is a hard sell in big tech
#124Quality is expensive. Even a fairly minor improvement in basic Quality can double the cost of implementation. But, in my opinion, it’s absolutely required for complex systems, and complex problems often need complex answers, despite the wish for simplicity (which can sometimes happen, but less frequently than people might think). I had an online back-and-forth, the other day, with someone that didn’t seem to be able…
> 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 .
You'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.
Re: Quality is a hard sell in big tech
#125Earlier quoted context omitted.
My manager talks the talk about how every developer in the team should be able to do all tasks. Why are we waiting for the database administrator guy to do the SQL part instead of doing it ourselves and yet I have a feeling he is not even a developer at all. At least my skip clearly has some development experience and even some self awareness that what used to be "best practices" then are now known to be bad now but…
> every developer in the team should be able to do all tasks I hate this. People have strengths, even if they’re all technically backend / frontend / whatever. Should you have more than one person who can perform a given task? Ideally yes, but let’s not pretend that Alice isn’t objectively better at SQL than James, but worse at async functions. Let people do what they’re best at, and enjoy the most.
I could see why management wouldn’t want to do that. By not getting Alice some practice on async functions, aren’t they making the team more fragile? Everything in moderation of course, but the team wouldn’t want to start leaning on each other’s specialization to the point that it all falls apart if somebody quits.
Re: Quality is a hard sell in big tech
#126Quality is expensive. Even a fairly minor improvement in basic Quality can double the cost of implementation. But, in my opinion, it’s absolutely required for complex systems, and complex problems often need complex answers, despite the wish for simplicity (which can sometimes happen, but less frequently than people might think). I had an online back-and-forth, the other day, with someone that didn’t seem to be able…
> 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 .
> 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).
Re: Quality is a hard sell in big tech
#127Quality is expensive. Even a fairly minor improvement in basic Quality can double the cost of implementation. But, in my opinion, it’s absolutely required for complex systems, and complex problems often need complex answers, despite the wish for simplicity (which can sometimes happen, but less frequently than people might think). I had an online back-and-forth, the other day, with someone that didn’t seem to be able…
> 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 .
Personally 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.
Re: Quality is a hard sell in big tech
#128Quality is expensive. Even a fairly minor improvement in basic Quality can double the cost of implementation. But, in my opinion, it’s absolutely required for complex systems, and complex problems often need complex answers, despite the wish for simplicity (which can sometimes happen, but less frequently than people might think). I had an online back-and-forth, the other day, with someone that didn’t seem to be able…
Yes, though I’d say high quality is expensive at first. Low quality is more expensive in the long term.
Re: Quality is a hard sell in big tech
#129Earlier quoted context omitted.
> 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 .
> 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…
I 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.
Re: Quality is a hard sell in big tech
#130Earlier quoted context omitted.
> 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 .
Personally 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.
I 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...