6 ms·

I'd rather have confusing software that does what I want, than simple software that doesn't do what I want. I'd suggest the proper response to this is, "Make t

I'd rather have confusing software that does what I want, than simple software that doesn't do what I want. I'd suggest the proper response to this is, "Make the common case easy, make the uncommon case possible."

collyw 10y ago
Sensible defaults.
djrobstep 10y ago
I'd rather have simple software that does what I want.
- sz4kerto 10y ago
  Then either other people don't have the software what they want (because there are so many different needs when it comes to any domain) or the complexity is transferred to finding/evaluating the huge selection of software.
- etatoby 10y ago
  LOL that's called having your cake and eating it too, AKA impossible.
- felipeerias 10y ago
  Exactly. Our tools should not add a layer of unnecessary complexity on top of already complex domains. If anything, they should take complexity away so we can focus on what is most relevant for the goals that we want to achieve. A lot of configuration options come into existence not because they are actually useful, but because the team had a disagreement that they couldn't settle, or because writing code that just figured out the right thing to do would be too complex. Options should be a way of empowering the user, not simply offloading work to them. It's very important to realise that our goals are not just related to the concrete problem at hand, but include things like "get out of the way and don't make me feel stupid".
  - TeMPOraL 10y ago
    But then a lot of options exist because the domain itself is complex and can't be captured in a one-size-fits-all solution. The only way to make something both very simple and very useful for a domain is to cunningly cut out parts of the domain. The end result is a pretty, simple and opinionated tool that doesn't really solve anything for anyone, but sure looks good on screenshots.
    - thaeli 10y ago
      This. Most "disagreements a team can't settle" are rooted in fundamentally different use cases of a complex domain.
adrianN 10y ago
I'd rather have five simple tools that do what I want than one tool that can in principle do what the five tools do if you massage its configuration enough.
- pron 10y ago
  Why? And what if that one tool came with five common configurations for the five usages?
  - adrianN 10y ago
    Because simple tools are easy to understand and easy to replace when you find something better. Once you invested a lot of time into configuring your GenericTool(tm) to do what you want you're locked into its ecosystem forever. Also, simple tools that do one thing only tend to do it better than tools that do lots of things.
    - pron 10y ago
      What if that one tool came with five configurations for your five usages, that you wouldn't have to touch? You can still replace one usage with another tool, if you like. I think that the idea of many simple tools is good in theory, but seeing that most important codebases last for ten or twenty years, use of many tools increases the likelihood that you've introduced a dependency on a product that may be discontinued/unmaintained. "Easy to replace" is fine if you're very familiar with the code and all the assumptions it makes about the product's behavior, but if a tool that some module of your system that no one has touched in more than five years all of a sudden disappears[1], replacing it may be almost as big an undertaking with replacing the one big tool, but the chances of that happening are greater (because you have more such tools, and small tools are more likely to be discontinued than big ones). [1]: Say, by no longer supporting your new hardware/OS.
      - adrianN 10y ago
        Replacing just part of a big tool because there is a better alternative doesn't fly with management ("we already paid for big tool and it does what you want, why should we replace a part of it? It will just increase the complexity!"). I see small tools disappearing occasionally as a good thing. You should always be prepared to change parts of your system and a larger organization should have people that continuously work on improving the tooling. Assuming that your tooling will work indefinitely leads to ossified systems that can't be upgraded at all. Imho, tools should be treated just like code. You wouldn't write one big function that takes half a dozen parameters to change its behavior. You refactor it into multiple functions that are easier to understand and improve when requirements change.
rasz_pl 10y ago
I remember learning a saying years ago on slashdot. Difference between Windows and Linux: easy things are difficult in Linux, difficult things are possible. Easy things are trivial in Windows, complicated things are impossible. This was in XP era. Today the likes of Ubuntu/Gnome try their best to dumb down Linux.
jamesroseman 10y ago
The real takeaway here should be that engineers tend to make UX that feel good to them as engineers, and most of their clients will typically not be engineers. > I'd rather have confusing software that does what I want, than simple software that doesn't do what I want. Of course you would, or I would, or anyone who browses HackerNews would -- but it's not necessarily the best UX.
- xixi77 10y ago
  If this is a business software, once the sale is done, users are going to pick it up because they pretty much have to. But the sale can easily fail in the first place if the product does not have a feature that particular customer wants, and the competing offering does.

collyw 10y ago

Sensible defaults.

djrobstep 10y ago

I'd rather have simple software that does what I want.

sz4kerto 10y ago
Then either other people don't have the software what they want (because there are so many different needs when it comes to any domain) or the complexity is transferred to finding/evaluating the huge selection of software.
etatoby 10y ago
LOL that's called having your cake and eating it too, AKA impossible.
felipeerias 10y ago
Exactly. Our tools should not add a layer of unnecessary complexity on top of already complex domains. If anything, they should take complexity away so we can focus on what is most relevant for the goals that we want to achieve. A lot of configuration options come into existence not because they are actually useful, but because the team had a disagreement that they couldn't settle, or because writing code that just figured out the right thing to do would be too complex. Options should be a way of empowering the user, not simply offloading work to them. It's very important to realise that our goals are not just related to the concrete problem at hand, but include things like "get out of the way and don't make me feel stupid".
- TeMPOraL 10y ago
  But then a lot of options exist because the domain itself is complex and can't be captured in a one-size-fits-all solution. The only way to make something both very simple and very useful for a domain is to cunningly cut out parts of the domain. The end result is a pretty, simple and opinionated tool that doesn't really solve anything for anyone, but sure looks good on screenshots.
  - thaeli 10y ago
    This. Most "disagreements a team can't settle" are rooted in fundamentally different use cases of a complex domain.

adrianN 10y ago

I'd rather have five simple tools that do what I want than one tool that can in principle do what the five tools do if you massage its configuration enough.

pron 10y ago
Why? And what if that one tool came with five common configurations for the five usages?
- adrianN 10y ago
  Because simple tools are easy to understand and easy to replace when you find something better. Once you invested a lot of time into configuring your GenericTool(tm) to do what you want you're locked into its ecosystem forever. Also, simple tools that do one thing only tend to do it better than tools that do lots of things.
  - pron 10y ago
    What if that one tool came with five configurations for your five usages, that you wouldn't have to touch? You can still replace one usage with another tool, if you like. I think that the idea of many simple tools is good in theory, but seeing that most important codebases last for ten or twenty years, use of many tools increases the likelihood that you've introduced a dependency on a product that may be discontinued/unmaintained. "Easy to replace" is fine if you're very familiar with the code and all the assumptions it makes about the product's behavior, but if a tool that some module of your system that no one has touched in more than five years all of a sudden disappears[1], replacing it may be almost as big an undertaking with replacing the one big tool, but the chances of that happening are greater (because you have more such tools, and small tools are more likely to be discontinued than big ones). [1]: Say, by no longer supporting your new hardware/OS.
    - adrianN 10y ago
      Replacing just part of a big tool because there is a better alternative doesn't fly with management ("we already paid for big tool and it does what you want, why should we replace a part of it? It will just increase the complexity!"). I see small tools disappearing occasionally as a good thing. You should always be prepared to change parts of your system and a larger organization should have people that continuously work on improving the tooling. Assuming that your tooling will work indefinitely leads to ossified systems that can't be upgraded at all. Imho, tools should be treated just like code. You wouldn't write one big function that takes half a dozen parameters to change its behavior. You refactor it into multiple functions that are easier to understand and improve when requirements change.

rasz_pl 10y ago

I remember learning a saying years ago on slashdot. Difference between Windows and Linux: easy things are difficult in Linux, difficult things are possible. Easy things are trivial in Windows, complicated things are impossible. This was in XP era. Today the likes of Ubuntu/Gnome try their best to dumb down Linux.

jamesroseman 10y ago

The real takeaway here should be that engineers tend to make UX that feel good to them as engineers, and most of their clients will typically not be engineers. > I'd rather have confusing software that does what I want, than simple software that doesn't do what I want. Of course you would, or I would, or anyone who browses HackerNews would -- but it's not necessarily the best UX.

xixi77 10y ago
If this is a business software, once the sale is done, users are going to pick it up because they pretty much have to. But the sale can easily fail in the first place if the product does not have a feature that particular customer wants, and the competing offering does.