A generalization is not the same as a universal claim, which can be disproved with a single exception.
A generalization is about the shape of some statistical cloud. We have to show that it's not shaped that way to disprove it. So find enough exceptions and we're there. But how many are enough?
It's usually easiest (imho) to disprove these by showing a different generalization that is true, but conflicts with the given one.
No other shell or programming language comes close out of the box at the versatility that Bash has. I say this after having searched high and low for shell programming languages, maintaining big bash projects for a multiple organizations.
There are idiosyncracies to java, c, go and rust too. This monoculture of bash is bad is tiring. Paired with the monoculture of go is the new hotness. I rewrote at 500 line python project in 100 lines of bash for more functionality, but at a cost of more external dependencies but they are system deps with a standard abi without having to deal with python. APL has its strengths where Go/Rust is terrible.
Just use the correct tool for the job. And no more of this monoculture. Diverse problems need diverse solutions
A lot of people love bash, and a lot of people bash bash, but I'm personally aware that not "virtually everyone" hates it.
Standing up an idea well enough to change how people see a need is an incredible accomplishment but it's entirely different from single-handedly knowing how to make it work best for people who use it. Or for anybody other than you, really.
But underestimating the importance of, or even disdain for deliberate usability work is pervasive in FOSS. Most developers see interfaces as a place to expose the user-facing functionality so people can interact with your software. To a user, the interface is the software. In their estimation, bad interface=bad software.
When projects ignore that, they end up making Gimp.
You'll have a hard time selecting a sample of serious photo editors where fewer than 80% have tried Gimp— yet maybe %5 use it. Fewer will have heard of the younger commercial Affinity, but more will use it. (edit: obviously pulling those numbers out of my ass but I've been editing photos on computers since the early 90s and do so professionally to this day.)
However, in the adjacent and oft-overlapping world of vector art, the FOSS project Inkscape is very, very popular— even among professionals. They aren't hostile to usability changes, actively seek outside interface design perspectives and have a usable application because of it.
Inkscape does more good for a broad swath of vector artists because of their good design habits. Gimp has a product enjoyed by open source enthusiasts with light photo editing needs.
Free + great enough to generate word of mouth will trump expensive + great + advertising in almost every case.
Problem Discovery - listen to users to understand where they struggle, but ignore their proposed solution and desires (except to the point it helps you understand the problem they are attempting to communicate).
Solution Discovery - design a solution that addresses the problem, and validate it with real usage. Importantly not just talking, but users need to actually try it out.
Cooper and Vlaskovits - The Entrepreneur’s Guide to Customer Development
You don't have to do exactly what they suggest, but following that advice I'd expect to see a lot of solutions that miss the mark in subtle ways that would be really frustrating as a user. Sometimes people don't fully understand why "Do thing Y instead" would make it better, so it's not in their "Problems" section, but they for sure know that having the button do Y instead would solve it. It's probably worth thinking about and not ignoring.
I had one set of legacy workflows I once replaced that rough went like:
1) Export data from system A to a CSV.
2) Remove/reorder a few columns manually in excel
3) Get manual approval from a manager
4) Email to different department
5) Upload to system B via their import function
The request was to just give us an "export with the right format," thus replacing step 1 & 2. But we also heard complaints from the team doing step #5 that it was pointless and could be automated, and from the managers in #3 that really they used a simple rule that if X < Y approve otherwise deny.
So we thought we could build a workflow automation that connected the two systems via API, with an automated approval and flag those that didn't meet the rule for manual review.
So we propose this, everyone agrees. We build a pilot, test it, everyone likes it. Then go to release it and find out that this ignores any number of cases where in #2 there where hidden workflows like "any time you see scenario W, send it to Jenny and she runs a formula on these columns to adjust" or "actually the manager never approves anything from this department related to an acquisition because of factor x, and it needs to go to this different group." There was about a dozen similar requirements. Could we have identified these sooner? On other projects we usually did, but this project went further than most before they were detected.
We ended up temporarily building that export button requested by the users originally and were planning to fix the API based workflow ... but then there was a reorg and priorities shifted. We never came back to project and AFAIK those groups still work via email. But they don't do nearly as much excel busywork as before ¯\_(ツ)_/¯
Search "shutting down" on HN for a list: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
It reminds me of what is important in life.
They're talking about a bottom-up model of sales rather than top-down.
Selling to the end users of a platform rather than selling to the CIO/CTO.
This is particularly important now in the age where lots of SWEs won't take a job if the company is using teams/outlook and not slack.
it's not necessarily the best approach, but as long as there's money to be made out of it, there will be customer tailored software.