Comment by llmslave2
3 days ago
I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair.
In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.
When you're not shipping, you're not learning from users. As a result, it's easy to build working, correct, performant code which doesn't fit what anyone actually needs.
I think you can also learn from users when they complain en masse about the current atrocious state of software quality. But I guess that doesn't show up in telemetry. Until it does. Looking at you, Microsoft!
I believe one of the main reasons why Windows 11 is getting so much vitriol is that Microsoft is focusing on customers, which aren't always identical to users. Most of the time, when you buy a Windows-based device, you're not their customer: you're the OEM's customer, and for the OEM, every nickel of expenses counts. On the other hand, direct Microsoft licensees, such as corporate ("enterprise") customers, get much more attention from the company and a significantly better experience.
You can't learn from this because users always complain no matter what.
The trick is they just complain about the last thing they remember being bad, so it's a good sign when that doesn't change, and it's bad if they start complaining about a new thing.
Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop. That's just an excuse.
This is analagous to the problem of premature optimization - if you try to optimize performance without benchmarking, you end up eating a lot of time and effort on things that don't matter. Likewise for product: it is very easy to solve the wrong problems.
ridiculous.
> Figuring out what is useful for people is not some difficult problem that requires shipping half baked slop
what have you shipped? paying sees literally hundreds of thousands of dollars a year to ship out fledged out software that no one wants is exactly why Stadia lasted both way too long and got cancelled anyway.
figuring out what is useful is the hardest problem. if anything that's Google's biggest problem, not shipping fast enough, not iterating fast enough.
1 reply →
I wish people who ship crappy software didn't ship it and would let someone else ship something better instead.
It really sucks when the first mover / incumbent is some crappy half assed solution.
But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality
Linux kernel - free Unix.
JavaScript - scripting in browser
Python - sane "perl"
Today on GitHub alone you can probably find 100 more featured and higher quality projects than any of these were when they launched but nobody cares.
While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.
That's the other side of the value added coin. Users sometimes find value even in the half assed software.
Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".
1 reply →
WRT Linux. Sure, 1991 or really even mid-90s Linux was clearly immature. But Wall Street was adopting it instead of Solaris by the turn of the century. Plus "open source" so it wasn't the case of a new proprietary Unix just emerging from the sea foam which no one wanted anyway but Linux becoming the good enough Unix standard which is what people did want.
existing is better than not existing and those who move fast and ship crappy software first will win. learn the lesson :)
how does the Linux kernel lack quality?
It did in the early days, especially up until 2.4 which was generally considered the first enterprise-ready kernel version. (You can argue about whether the old "enterprise-capable" definitions still applied but they were a benchmark for a lot of people.) Of course, lots of ancillary stuff too in userspace and outside the kernel related to filesystems and the like.
4 replies →