[HN Gopher] Fast Software, the Best Software (2019)
___________________________________________________________________
Fast Software, the Best Software (2019)
Author : Tomte
Score : 78 points
Date : 2022-11-13 17:08 UTC (5 hours ago)
(HTM) web link (craigmod.com)
(TXT) w3m dump (craigmod.com)
| [deleted]
| taeric wrote:
| This was quite a ride. Very stream of conscious feel. Such that I
| don't want to get too caught in the examples.
|
| > I don't think I'm invoking some halcyon fantasy.
|
| That said, the above is in fact a fantasy. Isn't necessarily
| wrong, but your average computer image in the 90s is laughably
| small compared to today. Such that just opening the app is likely
| processing more than was even possible in the 90s.
|
| This also means strategies that were fine back then, such as
| indexing everything on a personal computer so that it could feel
| snappier, work against the goal.
|
| People want faster applications, but we don't really have a route
| to letting them do fewer things. And I assert that is a large
| part of why things were maybe faster back in the day.
| jt2190 wrote:
| > But why is slow bad? Fast software is not always good software,
| but slow software is rarely able to rise to greatness. Fast
| software gives the user a chance to "meld" with its toolset. That
| is, not break flow. When the nerds upon Nerd Hill fight to the
| death over Vi and Emacs, it's partly because they have such a
| strong affinity for the flow of the application and its
| meldiness. They have invested. The Tool Is Good, so they feel.
| Not breaking flow is an axiom of great tools.
|
| To add some hard data to this, the "eight second rule" [1][2] is
| the maximum amount of time a user, on average, of a system can
| wait for that system to return control back to the user without
| the user having some other thought pop into their brain,
| interrupting their flow.
|
| [1] Response Times: 3 Important Limits (2010)
| https://www.nngroup.com/articles/response-times-3-important-...
| says it's more like ten seconds
|
| [2] Website Response Times (2010)
| https://www.nngroup.com/articles/website-response-times/
|
| [3] The Need for Speed, 23 Years Later (2020)
| https://www.nngroup.com/articles/the-need-for-speed/
|
| Edit: Added reference
|
| Edit 2: Additional reference
|
| Edit 3: One more reference
|
| Edit 4: I think there are still many many opportunities to
| improve flow in many processes. Top of my list would be keeping
| compile times in the single-digit seconds.
| coliveira wrote:
| Sadly, the future of software is to become bloated and slow,
| for business reasons. Any software that is not bloated has
| fewer features, and can be relatively easily duplicated by a
| competitor. From a business standpoint, this is bad and a
| danger for the company survival, as it can now be replaced by a
| competitor that can crank more features into the product. By
| adding more features, companies pretty much guarantee that the
| software will also be slow, at least for a significant number
| of user cases.
| kragen wrote:
| as long as free software allows users to choose fast software
| instead of business software this shouldn't be a problem, but
| the web browser disaster is an instructive tale of how this
| can go terribly wrong
| RedShift1 wrote:
| That reference is from 1993... I think people's attention span
| has shortened since then...
| codetrotter wrote:
| > I think people's attention span has shortened since then...
|
| Unlikely. Rather, what I think has happened is that as the
| internet keeps filling up with more and more trash, we have
| been forced into being harsher with our willingness to pay
| attention to any one specific thing. In other words, it's not
| the attention span that has changed. It's the signal to noise
| ratio that keeps getting worse and worse. And that's why you
| need to demonstrate value to your audience quickly or
| otherwise they will move on to the next thing. But don't
| blame the audience for that. Blame the producers of the
| content.
| jt2190 wrote:
| What you're calling "attention span" is probably more
| accurately called "user expectations", or "user patience"
| which, obviously, can easily change.
|
| On the other hand, there seems to be a measurably consistent
| maximum amount of time that one can tolerate a pause without
| also breaking out of flow. This might be cultural, but it
| seems to be consistent enough that it could be physiological.
| Tempest1981 wrote:
| Agreed, 140 char replies instead of paragraphs, and rapidly
| scrolling TikTok videos. We need that dopamine.
| auggierose wrote:
| A friend of mine has a very interesting view with regards to
| flow: It is a bad thing. You don't want to be in a state of
| flow, because you are not thinking hard enough about what you
| are doing then, but just following the flow.
| kragen wrote:
| being in a state of flow as defined by csikszentmihalyi has
| nothing to do with 'just following the flow'
|
| on the contrary, it is when you are in a state of flow that
| you are thinking hardest about what you are doing
|
| it sounds like your friend got confused by a random
| coincidence of word meanings
| BiteCode_dev wrote:
| Being in the flow is not being on automatic.
|
| It's the absolute opposite, you are totally conscious about
| what you are doing, and clear headed about the decisions you
| make.
|
| It does feel effortless, but not in the sense that you are
| not doing the thing consciously, rather in the sense that the
| thing seems so obvious and easy as you perform in perfect
| fluidity.
| openfuture wrote:
| The way it has been described to me is that if you always
| take the same route to work then your cognitive performance
| goes down. Staying curious and exploring the different routes
| is hard with relatively few waypoints but then you can zoom
| into more granular decisions (or out ... to the causes).
| randiRando wrote:
| That is a very _interesting_ take. I think it's ~wrong but,
| like most interesting takes, there's some truth to it. I
| think the "truth" here is that, well yeah you're not thinking
| about some things, that's literally what I consider flow,
| it's not thinking about **how** you're going to do X but it's
| higher level than that and focusing on "do x".
|
| I think it's the difference between thinking/taking the
| action "walk to the door and open" (X in the flow state) and
| "ok get up, left leg forward, right leg forward, left leg
| forward, right leg forward, move arm to door, grab, twist,
| pull". Flow is just not thinking about the things that are
| not important (a lot of code is just gluing and can be done
| in a flow state - still allowing you to stop and think about
| the real important places). What your friend is calling out
| is that yeah I guess that sometimes you can "automate"/flow
| things that actually are important but to be honest I don't
| think that happens very often in this context (software, real
| use(r)-cases) because their use-case are usually so narrow
| and specific (we should design software to allow them to
| "flow" the unimportant stuff - click next for the additional
| questions - did you notice the button responds on mouse click
| up? I hope not, I hope we made that piece "flowable")
| marcosdumay wrote:
| There is something to be said about flow in mechanical
| activities, because on those, yes, you are mostly not
| thinking, just following the "rhythm". Safety is normally
| one of the first things to get out of your head during
| that.
|
| But programing is nothing like mechanical activities.
| wizofaus wrote:
| But the act of typing on the code and running/debugging
| it should be. Any toolset where you have to wait
| excessive amounts of time just to be able edit/
| compile/launch/debug/review results is not really going
| to make you think more carefully about your code (an
| exception could be made for super long compile times,
| which do force you to be more careful with what you
| input, but I'm not really convinced it can help you write
| better code).
| [deleted]
| omnicognate wrote:
| I don't think I'd go as far as to claim flow is _bad_ , but
| there's something to that.
|
| I'm a long term emacs user and between changing keyboards a
| few times and an unfortunate spell of a few years using an
| IntelliJ-based IDE with Emacs Keybindings that are far better
| than most but inevitably _off_ (most infuriatingly, to
| conclude an incremental search you use Ctrl-g, which in
| actual emacs jumps you back to where you started the search)
| my reflexes are all over the place. I 'm therefore having to
| force myself to slow down and be consciously aware of
| everything I do.
|
| I'm finding it a really useful exercise for more than just
| the retraining aspect. It does seem to increase my overall
| engagement with the task I'm carrying out, beyond just the
| operation of the tool.
| commandlinefan wrote:
| I die a little inside every time I lose an argument over whether
| or not we should spend time optimizing our software (I lose that
| argument every time I have it).
| taeric wrote:
| Pro tip, as soon as you are arguing over the code, you've
| already lost.
|
| Most places are so far behind on priority tasks, that to slow
| down and discuss/debate the priority of tasks is likely to just
| cause more issues.
|
| It isn't that you are even wrong. You almost certainly aren't.
| But nobody will wait for things to get better. If you stall out
| on features while prioritizing, you will lose folks.
|
| Unfortunately, I don't have a legit answer/solution. My view is
| it is a lot like keeping a clean kitchen. That is table stakes
| and assumed. Such that folks in a kitchen have to create a
| somewhat self cleaning flow of things. Similarly, you have to
| constantly optimize and clean up the code as you go. Double
| down on what you have, and constantly work to improve it. Not
| to replace it.
| [deleted]
| trabant00 wrote:
| I have the same obsession for speed and I have given up on
| desktop environments years ago, ending up on with i3 and mostly
| CLI. These past years I was forced for some periods to work on
| macOS, Windows and Gnome. While they clearly work I simply can
| not stand them. My muscle memory starts an application then
| immediately start typing and to my surprise something else
| happens, because the app has not started yet and I still have
| focus in another window or in the desktop. Or I chain keyboard
| shortcuts and the same unexpected results happen because the
| previous command has not completed. It forces me to wait and pay
| attention to what the system is doing and this annoys me to no
| end.
|
| I know plenty of people being a lot more productive than me using
| slow and not very ergonomic environments. So I understand this is
| just an obsession of mine and not necessarily justified. But once
| I got used to instant everything it's so hard going back.
| keizo wrote:
| Awesome! I feel like years ago there was so much focus on speed.
| We'd optimize websites for 56k modems. Now day much of the saas
| software i started using years ago has become worse with modern
| spa frameworks. FreshBooks was a big one. Even Shopify I find
| frustrating.
|
| Last couple years I've been on roam research for note taking. But
| takes more than 8 seconds to load for me. So slow I'm diy mission
| to make my own solution. Will have to check out nvalt though.
| thewebcount wrote:
| I had to laugh at this:
|
| > Similarly, I started using Lightroom around 2007 because it was
| so much faster than Apple's Aperture.
|
| I had the exact opposite experience. I used Aperture because it
| was so much faster that Lightroom. I could apply the same changes
| to multiple files at once, which at the time, at least, Lightroom
| couldn't do. You had to work on each file separately. If you did
| a burst on manual, Aperture's workflow was waaaay faster. I'm
| still sad Apple end-of-life'd it.
|
| Other than that I agree with the spirit of the article. I love it
| when software is so fast you don't even have to think about the
| software. It's so rare these days, especially with web apps.
| aetherspawn wrote:
| It's my observation that only developers really notice or care
| about speed. As long as something is "fast enough" (and the
| benchmark here is pretty low), most people won't specifically
| choose a fast app over a slow app with more features.
|
| This means that sometimes we put too much emphasis on speed. But
| it is not as important to everyone else as it is to us. A product
| with the defining feature "it is fast", usually fails to get
| noticed except by other developers.
| alkonaut wrote:
| Exactly this. I develop really "heavy" desktop apps for a
| living and this is my experience too. End users are solving a
| problem and that problem might be "producing a quote for a
| machine for a customer". If that took them an hour in the
| snappy but feature-lacking old software, and a new new software
| does it with enormous bloat, frustrating pauses, crashes but in
| half the time, then customers will love it and praise it.
|
| When there is a bug report for a performance issue it's rarely
| some minor delay but usually something absurd like a 15 minute
| wait due to something accidentally quadratic.
|
| If you ask customers of course they won't prefer the 2 second
| improvement for the function they use hundreds of times per day
| because it only saves them a few hundred seconds. They'd rather
| have one more feature that saves them 30 minutes every week
| instead. And the thing is there is an endless number of such
| features even after 200 man years of dev.
|
| At the same time, as a developer I have almost no understanding
| for this mindset. If I was forced to work with slow and
| frustrating software all day I'd quit and grow potatoes for a
| living instead (and I use visual studio so my treshold for
| bloat and frustration is pretty high).
| californical wrote:
| I understand where you're coming from, but when you have expert
| users of your software, they'll be extremely sensitive to
| speed. Maybe a casual user won't care, though.
|
| For example, my company has a team of experts who use our
| internal tool for managing company-related tasks. They use this
| tool every day as a core part of their job. It's a team of
| literally hundreds of people who use this tool.
|
| If we add a feature which adds a click to some step of
| something they're used to doing, we'll never hear the end of
| it. Their team celebrates whenever we can add any sort of speed
| increase to something they've been using for a while. Adding
| shortcuts to common functionality is always a big user request.
|
| It's obviously not a core part of our job to consider only
| performance, we add and change lots of features all the time.
| But if we ever neglect performance for too long, it can really
| start to weigh their team down.
|
| It's interesting working so close to the people who use the
| software, because they don't hesitate to give feedback like
| that, which you'd never get from just an internet software
| release. Lots of other software will have these "expert users"
| too, but you won't hear the feedback.
| properparity wrote:
| There's several GB/s of bandwidth from disk to screen these days,
| so unless you're processing several GB of data you have no excuse
| for anything in your programs to take more than a second.
|
| It's an insult really, such incredible waste of all the potential
| processing power we all have.
| Gigachad wrote:
| They don't need an excuse. They just spend their time adding
| more features instead of speeding things up. And all the users
| flock to their tool over yours because the extra feature saved
| them hours in their process while your performance optimization
| saved seconds but took the same dev time.
| commandlinefan wrote:
| And your boss will insist that it doesn't matter, if
| optimization takes more than a day to do.
___________________________________________________________________
(page generated 2022-11-13 23:00 UTC)