9 ms·

I think the hyper-focus on customer desires is a misstep. The best and most widely-adopted software in history has been software designed by a couple of visiona

I think the hyper-focus on customer desires is a misstep. The best and most widely-adopted software in history has been software designed by a couple of visionaries (or at most a small team) who ignored what users _said_ they wanted and gave them what they needed instead.

great_wubwub 5y ago
Sure, but I think you have some survivor bias here. How many people turned out some software that they thought people needed but which nobody did? I don't have any examples at hand but it's gotta be a whole lot.
- visarga 5y ago
  99% of github?
  - rjbwork 5y ago
    Ahh, an optimist!
- mooreds 5y ago
  > How many people turned out some software that they thought people needed but which nobody did? Search "shutting down" on HN for a list: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=shutting%20down&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
  - GreenWatermelon 5y ago
    Man... it's like a graveyard and the titles are tombstones.
    - mooreds 5y ago
      I often think about how little code I've written over the decades is still being run. Not much. It reminds me of what is important in life.
      - c-linkage 5y ago
        To crush your enemies, to see them driven before you, and to hear the lamentations of their women?
  - sdf4j 5y ago
    Can't beat the "shutdownify is shutting down".
- polote 5y ago
  The point is not that every opinionated piece of tool is good, the point is that the best ones are opinionated.
jacobr1 5y ago
The best model I've read about this is to separate feedback loops into two categories: 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.
- rapnie 5y ago
  Do you have a resource that explains this is more detail?
  - jacobr1 5y ago
    Ash Maurya - Running Lean Cooper and Vlaskovits - The Entrepreneur’s Guide to Customer Development
  - chefandy 5y ago
    While not a direct response to the two-lane idea, if you're interested in exploring these processes in general, searching for "design process" will get you a ton of info. In much of the design world, though especially in UX, design process navel gazing is somewhat akin to tech stack navel gazing among web developers.
- ehnto 5y ago
  Someone using your product probably does have a decent grasp on what a good solution would be, at least from the point of view of the user interface. We built a product that's broken for their use case in the first place, what makes us think we'll get it right the second time without their input? 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.
beebmam 5y ago
I think these kinds of generalizations are pretty absurd, as I can immediately think of counterexamples. Bourne shell (and by extension, bash) is by far one of the most common pieces of software used in the world, and has been hated by virtually everyone since it's release, including admissions by its own author that it is an inferior shell. It's certainly one of the most-widely adopted pieces of software in history; no shell comes anywhere close except maybe Microsoft DOS/cmd during a small time window.
- bfox 5y ago
  Context matters, no? I didn't say bash was inferior to other Bourne-alike shells. I said Bourne-alike shells all suffer from a common problem - they have to implement a "language" that has inconsistencies in it. A lot of people love bash, and a lot of people bash bash, but I'm personally aware that not "virtually everyone" hates it.
- drewcoo 5y ago
  I also think it's silly, but . . . 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.
  - pagutierrezn 5y ago
    I love the way you've formulated that concept. Thanks.
- deleted 5y ago
  [deleted]
- demouser345 5y ago
  I made this account to dispute this garbage. 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
chefandy 5y ago
Maybe you mean visionaries started those projects. Did any remain relevant without significant user and designer input? 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.
lamontcg 5y ago
That doesn't contradict this article. 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.
GarethX 5y ago
I agree in part, at least the quote often applied to Henry Ford “If I had asked people what they wanted, they would have said faster horses” rings true. But I think that only really applies to the core innovation, actually turning that into a viable business requires a lot of customer understanding and getting user feedback is key to that. Rob Fitzpatrick's book "The Mom Test" explains how to get actually useful feedback from users.
avereveard 5y ago
enterprise may have situations where changing workflows is often more expensive than paying for developers to tune software to their need, even including long term consideration about customized software maintenance. 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.

great_wubwub 5y ago

Sure, but I think you have some survivor bias here. How many people turned out some software that they thought people needed but which nobody did? I don't have any examples at hand but it's gotta be a whole lot.

visarga 5y ago
99% of github?
- rjbwork 5y ago
  Ahh, an optimist!
mooreds 5y ago
> How many people turned out some software that they thought people needed but which nobody did? Search "shutting down" on HN for a list: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=shutting%20down&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- GreenWatermelon 5y ago
  Man... it's like a graveyard and the titles are tombstones.
  - mooreds 5y ago
    I often think about how little code I've written over the decades is still being run. Not much. It reminds me of what is important in life.
    - c-linkage 5y ago
      To crush your enemies, to see them driven before you, and to hear the lamentations of their women?
- sdf4j 5y ago
  Can't beat the "shutdownify is shutting down".
polote 5y ago
The point is not that every opinionated piece of tool is good, the point is that the best ones are opinionated.

jacobr1 5y ago

The best model I've read about this is to separate feedback loops into two categories: 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.

rapnie 5y ago
Do you have a resource that explains this is more detail?
- jacobr1 5y ago
  Ash Maurya - Running Lean Cooper and Vlaskovits - The Entrepreneur’s Guide to Customer Development
- chefandy 5y ago
  While not a direct response to the two-lane idea, if you're interested in exploring these processes in general, searching for "design process" will get you a ton of info. In much of the design world, though especially in UX, design process navel gazing is somewhat akin to tech stack navel gazing among web developers.
ehnto 5y ago
Someone using your product probably does have a decent grasp on what a good solution would be, at least from the point of view of the user interface. We built a product that's broken for their use case in the first place, what makes us think we'll get it right the second time without their input? 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.

beebmam 5y ago

I think these kinds of generalizations are pretty absurd, as I can immediately think of counterexamples. Bourne shell (and by extension, bash) is by far one of the most common pieces of software used in the world, and has been hated by virtually everyone since it's release, including admissions by its own author that it is an inferior shell. It's certainly one of the most-widely adopted pieces of software in history; no shell comes anywhere close except maybe Microsoft DOS/cmd during a small time window.

bfox 5y ago
Context matters, no? I didn't say bash was inferior to other Bourne-alike shells. I said Bourne-alike shells all suffer from a common problem - they have to implement a "language" that has inconsistencies in it. A lot of people love bash, and a lot of people bash bash, but I'm personally aware that not "virtually everyone" hates it.
drewcoo 5y ago
I also think it's silly, but . . . 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.
- pagutierrezn 5y ago
  I love the way you've formulated that concept. Thanks.
deleted 5y ago
[deleted]
demouser345 5y ago
I made this account to dispute this garbage. 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

chefandy 5y ago

Maybe you mean visionaries started those projects. Did any remain relevant without significant user and designer input? 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.

lamontcg 5y ago

That doesn't contradict this article. 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.

GarethX 5y ago

I agree in part, at least the quote often applied to Henry Ford “If I had asked people what they wanted, they would have said faster horses” rings true. But I think that only really applies to the core innovation, actually turning that into a viable business requires a lot of customer understanding and getting user feedback is key to that. Rob Fitzpatrick's book "The Mom Test" explains how to get actually useful feedback from users.

avereveard 5y ago

enterprise may have situations where changing workflows is often more expensive than paying for developers to tune software to their need, even including long term consideration about customized software maintenance. 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.