4 ms·

I think users are expecting more, but not necessarily in the ways you are imagining. It's about how much of the process users expect to be automated vs how much

I think users are expecting more, but not necessarily in the ways you are imagining. It's about how much of the process users expect to be automated vs how much needs intervention. I'll redirect to my other comment: https://news.ycombinator.com/item?id=16261510 https://news.ycombinator.com/item?id=16261510 "Software is really about codifying process -- pun completely intended. What happens is some slick new software comes along that implements that happy 80% path on the process, and does it quickly and efficiently. Then business complains about the 20% falling into the gap, and starts adding features to reduce that, thereby slowing down the processing. This keeps going, until someone has an idea and implements slick new software that implements that happy 80% path on the process, and does it quickly and efficiently..."

ZenoArrow 9y ago
> "I think users are expecting more, but not necessarily in the ways you are imagining. It's about how much of the process users expect to be automated vs how much needs intervention." To a limited extent, yes, but if we're being honest here, the main "additional demands" that most users have for most new pieces of software are "simpler" and "prettier", neither of which automatically requires additional complexity under the hood.
- eropple 9y ago
  Faster very frequently is one of those demands, though--be it lower latency, quicker response to failure, whatever. And "fast" is hard, and "fast" very frequently does require the development of tools, and tooling, that understands and respects that need. Which is a big reason why, when I need a user interface, I write code in React: because I'm not waiting on page blanks or writing my own partial page composition stuff. And it's why I mostly use k8s and containers when working on devops-related tooling and architecture: because it's faster and better at reacting to failure cases than something I can build myself. (This wasn't always the case, but it's gotten there now.) Users also, for the most part, demand more correct. Not always, and not in all applications, but the tolerance for jank is going down over time. And this is a big reason why I use React and Redux: because React maps better to my understanding of how code works (namely, that extracting state to the imperative outer shell of the functional core leads to generally more correct and maintainable code) and Redux maps better to my understanding of how data works (namely, that specific and replayable transforms create manageable state). It's also a reason why I use containers: to turn the runtime environment into an "API" that is evaluated and tested in isolation from the "API consumer" that lives in the container. We are progressively moving towards software with these demands, too, and tools are evolving to respond to them. The panic around complexity is, IME, hyperbolic; a failure to choose tools with wisdom is endemic, it's not new.
- PeterisP 9y ago
  "Simpler" from the user's perspective does require additional complexity under the hood. It means that the "simpler" software has to be aware of all kinds of edge cases and solve them automagically, because the user expects a larger degree of automation. Software seems "simpler" to the user because it's working on a higher level of abstraction (and levels of abstraction tend to be "leaky") and by reducing the domain of details that the user needs to be aware of. In order to do that properly, the "simpler" software now needs code to take care of all those details as they are effectively removed from the user's awareness, while the earlier software could leave some of those edge cases up to the user.
  - ZenoArrow 9y ago
    > ""Simpler" from the user's perspective does require additional complexity under the hood." No, it doesn't, or at least it doesn't if you write the application in a language that is expressive enough to cater for the edge cases without bloating the code base. Consider a language like Red, which allows you to write GUI applications in a few lines of code. Must be a large runtime behind the scenes enabling this, right? It's clear that this is not the case as the runtime, compiler and libraries fit within 2MB. How is it possible for Red to achieve so much with so little? I'll leave that for you to discover for yourself.
    - jdmichal 9y ago
      The answer can't always be "a sufficiently-expressive language", same as the answer can't always be "a sufficiently-smart compiler". It looks like Red is a minimal programming language, with a purpose-built DSL ("dialect") for UI programming, which handles the "standardized" part. The final result of this line of thought would seem to be that everyone should use Lisp with layers of DSLs for whatever their target functionality is. Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself why that doesn't seem to happen. EDIT: As an aside, the Java 1.1 JVM was only about 15MB.
      - ZenoArrow 9y ago

ZenoArrow 9y ago

> "I think users are expecting more, but not necessarily in the ways you are imagining. It's about how much of the process users expect to be automated vs how much needs intervention." To a limited extent, yes, but if we're being honest here, the main "additional demands" that most users have for most new pieces of software are "simpler" and "prettier", neither of which automatically requires additional complexity under the hood.

eropple 9y ago
Faster very frequently is one of those demands, though--be it lower latency, quicker response to failure, whatever. And "fast" is hard, and "fast" very frequently does require the development of tools, and tooling, that understands and respects that need. Which is a big reason why, when I need a user interface, I write code in React: because I'm not waiting on page blanks or writing my own partial page composition stuff. And it's why I mostly use k8s and containers when working on devops-related tooling and architecture: because it's faster and better at reacting to failure cases than something I can build myself. (This wasn't always the case, but it's gotten there now.) Users also, for the most part, demand more correct. Not always, and not in all applications, but the tolerance for jank is going down over time. And this is a big reason why I use React and Redux: because React maps better to my understanding of how code works (namely, that extracting state to the imperative outer shell of the functional core leads to generally more correct and maintainable code) and Redux maps better to my understanding of how data works (namely, that specific and replayable transforms create manageable state). It's also a reason why I use containers: to turn the runtime environment into an "API" that is evaluated and tested in isolation from the "API consumer" that lives in the container. We are progressively moving towards software with these demands, too, and tools are evolving to respond to them. The panic around complexity is, IME, hyperbolic; a failure to choose tools with wisdom is endemic, it's not new.
PeterisP 9y ago
"Simpler" from the user's perspective does require additional complexity under the hood. It means that the "simpler" software has to be aware of all kinds of edge cases and solve them automagically, because the user expects a larger degree of automation. Software seems "simpler" to the user because it's working on a higher level of abstraction (and levels of abstraction tend to be "leaky") and by reducing the domain of details that the user needs to be aware of. In order to do that properly, the "simpler" software now needs code to take care of all those details as they are effectively removed from the user's awareness, while the earlier software could leave some of those edge cases up to the user.
- ZenoArrow 9y ago
  > ""Simpler" from the user's perspective does require additional complexity under the hood." No, it doesn't, or at least it doesn't if you write the application in a language that is expressive enough to cater for the edge cases without bloating the code base. Consider a language like Red, which allows you to write GUI applications in a few lines of code. Must be a large runtime behind the scenes enabling this, right? It's clear that this is not the case as the runtime, compiler and libraries fit within 2MB. How is it possible for Red to achieve so much with so little? I'll leave that for you to discover for yourself.
  - jdmichal 9y ago
    The answer can't always be "a sufficiently-expressive language", same as the answer can't always be "a sufficiently-smart compiler". It looks like Red is a minimal programming language, with a purpose-built DSL ("dialect") for UI programming, which handles the "standardized" part. The final result of this line of thought would seem to be that everyone should use Lisp with layers of DSLs for whatever their target functionality is. Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself why that doesn't seem to happen. EDIT: As an aside, the Java 1.1 JVM was only about 15MB.
    - ZenoArrow 9y ago