14 ms·

Performance Matters

401 points by MattGrommes 7y ago

ecpottinger 7y ago
I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are. Worse, I can use two different programs in Windows and one will be dog-slow compared to the other. I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there were for example programs having multiple version of the same library link into the code even while the program only used one library ever. Also the screen layout is runned thru a layout program/library that slows things down, the layout system is great when you are designing the system, but once you reach the point of final and fixed design there are faster ways to display it. on the other hand, management is too often cheap, and says "It works, don't it?" and do not want to pay for the extra coding that would make so much faster.
- cogman10 7y ago
  At least at my work, the issue is twofold. First, nobody measures performance. If they do, it is often done poorly (without using performance tools) Second, when performance is a problem, everyone guesses on the cause. Remember how they don't measure? Well, they also will say things like "this is probably slow because of X" where X is the database, the network, a method they hate, etc. Performance analysis requires accurate measurement.
  - leeoniya 7y ago
    this sounds terrifying. thankfully at my work nothing goes into production without a performance eval measured at least by Lighthouse & webpagetest on Fast 3G/2015 mobile/chrome. it's nice to be able to dictate these requirements ;)
- pjc50 7y ago
  Almost all of this stuff is caused by doing blocking IO on the UI thread. Unfortunately that becomes harder and harder to avoid doing by accident. And if part of the UI code or data gets paged out, there's a colossal hit to responsiveness.
- Crinus 7y ago
  The Windows vs Haiku case you describe is mainly a difference in terms of development culture. In Windows you can get similar fast performance and responsiveness by using the native GUI functionality, but most desktop applications nowadays use toolkits like Qt (at best) or Electron (at worst) that reimplement a ton of functionality that the OS itself already provides and treat it as something different than what it really is. On the other hand in Haiku everything uses the native Haiku APIs. But from what i've seen ever since Qt and Java were ported to Haiku, a bunch of applications started relying on those to run on it instead of using the native APIs (which IMO defeats the entire point of Haiku). Haiku does use a lot of prewritten libraries BTW, they're just hidden behind the scenes and shared among applications instead of each one bringing their own copy.
- gameswithgo 7y ago
  It isn't just management. Most software ecosystems (Rust, C, c++ excluded) discourage any thinking about or tinkering with performance knowledge. You see evidence of this on stackoverflow questions, questions on reddit and twitter. Young people or new programmers curious about the fastest way to do things are always lectured about how this is not good to do. It is quite unfortunate because building some experience for how to do things fast is very useful. It isn't always correct to optimize the hell out of things, of course, but we should encourage the curiosity behind it, so that more of us have the tools to do it when it is correct to do so.
  - mark-r 7y ago
    I have often found that doing things efficiently isn't really harder than doing them slow. So why not aim for software that's reasonably performant from the start? Sure you can micro-optimize to get every last nanosecond, but that's not what I'm talking about.
- kitsunesoba 7y ago
  The “leaning tower of abstractions” problem absolutely should be receiving more attention than it has been, because otherwise it’s only going to get worse. I don’t know what a fix looks like exactly, but something has to change.
- jodrellblank 7y ago
  Amiga at least, older computers were more responsive because they did less - directly attached video and keyboard hardware, no USB, no compositing video drivers, less font smoothing, and so on. See Dan Luu's analysis here: https://danluu.com/input-lag/ https://danluu.com/input-lag/ and here https://danluu.com/keyboard-latency/ https://danluu.com/keyboard-latency/ > Moreover, a modern computer with one of the slower keyboards attached can’t possibly be as responsive as a quick machine from the 70s or 80s because the keyboard alone is slower than the entire response pipeline of some older computers. Haiku (BeOS) was always promoted on its native multithreading and responsive UI, with early demonstrations showing windows being dragged around while playing video, IIRC, it's impressive that it still holds to that. But it also says a bit about what software people pay for and keep using - if sluggish Windows software has thrived, and BeOS crashed and burned. And then on Windows and Linux, light fast software gives way to bloaty huge sluggish software left and right.
ChrisSD 7y ago
> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.
- ziddoap 7y ago
  Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?
  - ChrisSD 7y ago
    Because that's literally the complaint as given. If the UI had reacted "instantly" it would be more user friendly. Even if the performance of the (non UI) code was slower. EDIT: Or to put it another way: "perceived performance can be more important than actual performance".
    - juliangoldsmith 7y ago
      Responsiveness is a result of adequate performance. The dropdowns that the article refers to are probably populated by a database, as opposed to being static. It doesn't matter if the dropdown opens instantly, what matters is that the information it contains is available.
  - 0xDEFC0DE 7y ago
    My take is that responsiveness has a cap of speed that’s pinned to human perception. Once you get here you can stop worrying about needing more. Performance does work as fast as possible regardless. You always want more but you’re capped by the system, hardware, and algorithms and not human perception. Feels like I’m splitting hairs though
    - viraptor 7y ago
agentultra 7y ago
I believe performance does matter and should factor into the design of a system. There is an ISO guidelines on software system requirements and specifications that has a section for performance requirements. It does matter even for banal, non-critical or non-life-threatening software systems. Another often-overlooked requirement: environment. Does the human using your software system have to pay attention to more important situations around them? Is the environment they're using your software in noisy, stressful, dangerous or dirty? Should you expect frequent wireless interference or degraded wireless performance? Reading the ISO specs are pretty boring, so is the SWEBOK guide, but it's rather interesting to think about software in terms of the whole system and not as an artifact unto itself.
- nickpsecurity 7y ago
  You'll probably like Nancy Leveson's model and work if you haven't seen it: http://sunnyday.mit.edu/accidents/safetyscience-single.pdf http://sunnyday.mit.edu/accidents/safetyscience-single.pdf http://sunnyday.mit.edu/ http://sunnyday.mit.edu/
- defined 7y ago
  I’m with you, but good luck getting some scrum shop to include enough detail to achieve this.
whistlerbrk 7y ago
As a former EMT and someone who built their own software to create run reports, I'm a bit skeptical as to that being the only reason. Paper can be edited, even after the point at which you given a carbon copy to a hospital, if you're friendly enough. This probably doesn't happen often or at all but there is a psychological safety there. People make small mistakes all the time on the ambulance in the rush to get them to the ER. We live in an extremely litigious society.
- ben509 7y ago
  That's a good insight. Never dealt with any medical stuff, but I dealt with paperwork in the military as it was going through a (long painful) transition to electronic documents back in the '00s. And I don't think it's just that society is litigous, but that databases actually (mostly?) work in terms of enforcing the rules you give them. One anecdote of how things changed was that you used to be able to arrive on post, and if you didn't like your orders, talk to a sergeant major of another unit and quietly get your orders changed, which no doubt drove PERSCOM crazy. When things were done with paper, there was a certain degree of flexibility in the rules that gave people some amount of local autonomy. When those rules are enforced by a computer, there's much less possibility of someone being able to override the rules when it makes sense. Normal human social interaction tends to create unwritten rules that are simply more flexible and realistic than the rules we're willing or able to write down.
  - abraae 7y ago
    We have a platform that amongst other things automates filling in a fairly complex government form, including online signature. We did a demo the other day to a large new customer. I learned that when they filled in the existing paper form, they didn't just sign it, they also stamped in the signature box with a little rubber stamp that "signed on behalf of the CEO". It wasn't immediately clear whether anyone handling the form was looking for that stamp, nor what they did when they saw it. As a result, it's not clear to us at this stage whether our pdf generation now needs a new feature to allow a user-uploadable image file to be imprinted over the form. That's the sort of thing you get with the joyous "flexibility" of paper.
shay_ker 7y ago
Did that quarter-second lag kill anyone? Was there someone who wouldn’t have died if the ePCR was just a little bit faster, fast enough to be usable? And the people who built it: did they ask the same questions? Did they say “premature optimization is bad” and not think about performance until it was too late? Did they decide another feature for the client was more important than making the existing features faster? Did they even think about performance at all? This seems like a lot of imagining of scenarios that may or may not have happened. Perhaps another way of looking at this is - did the company hired to build this actually care whether EMTs used their software, or were they looking to get a paycheck? So many health tech firms fall in the latter bucket. Such is the reality of the business - with huge enterprise sales funnels and hospital networks that don't understand the value of UX & great product (and caring a lot about their bottom line), this result isn't unexpected.
- JshWright 7y ago
  If someone is sick enough that a "quarter second" matters, there's zero chance the tablet is out in the first place. In reality if a quarter second is enough to kill someone, they're gonna die anyway...
  - bananocurrency 7y ago
    I feel the same about my EKG. What's a quarter second when it comes to measuring a heart? Who cares about precision.
    - JshWright 7y ago
      A quarter of a second in measurement resolution of an EKG is huge. An extra quarter of a second interpreting or documenting that EKG couldn't be any more meaningless.
Ensorceled 7y ago
When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, testing for drift in beta testing, etc. In our testing, 10 seconds was the absolute maximum time that a surgeon could "idle" and stay on task in surgery. In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration. The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.
- phkahler 7y ago
  >> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.
  - penagwin 7y ago
    I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.
    - jblow 7y ago
      The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system. It's just that modern software is garbage. That's all.
rossdavidh 7y ago
So, interesting and all, but it ignores the main reason for the advice to build it first, then optimize for performance, which is that if you build everything for performance from the beginning, you end up with a lot of code that is optimizing for performance of something that isn't the bottleneck. In other words, performance that doesn't show up in the user's experience, because something else is the main delay. Now, if all that meant was that the programmer has to do some more work, and you aren't worried about paying more for the software, this may not matter, but that is far from the only (or even most important) result of optimizing everything for performance. Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy. For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This can result in big improvements to software performance if done in the places which are the current limiting step, but now you have to make sure you invalidate the cache correctly. In particular, if you don't, you get stale values in the cache, which is to say false data. If you make a system with cacheing all over the place, it will be very hard to make changes correctly, which means sometimes they will get made incorrectly. In mission-critical systems, this is even less acceptable than elsewhere. It's not just "I don't feel like optimizing". More often, it's the cost of optimizing is not worth the benefit, for this particular part of the code. How do you know what spots in the code it's worth it? You don't optimize, at first, and then see which two or three spots in the system are rate-limiting.
- phkahler 7y ago
  >> For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This made me cringe. This is filling out a form. It could conceivably be a single record (or small set) in memory that gets committed/updated somewhere else in the background. Overly complicated solutions for simple problems are one of the primary things that kills performance. You don't have to optimize everything for performance, you just have to realize it's a primary feature and avoid doing anything that kills it. We carry super computers in our pockets, you don't have to write complex game code to get performance these days, just don't write shitty things.
jancsika 7y ago
Welcome to the world of soft realtime applications. Sounds like this one is just so bad that a) the designers didn't realize that was what they were designing and b) consequently it failed to meet any of its deadlines in the UI domain. One detail I've noticed is that even if you do a shitty job of hitting the deadlines, users will often find workarounds. As long as a critical mass of features respond consistently within the deadlines, users will fiddle around to make the rest work-- even if you tell them directly that it isn't possible. Say the dropdown menus here performed fast enough, but going to the "next page" required a bunch of DOM mutation or something that grinds to a halt for two seconds. I'd bet EMTs would have trained themselves to do branch prediction-- hit the button to change pages before setting it down, hit it again based on what the patient is communicating to the other EMT, and so forth. I've seen users do weirder stuff. The fact that they discarded it altogether tells you how bad the UI was.
wickerman 7y ago
I don't think the word performance is key, but rather /user experience/.
tabtab 7y ago
Quote: It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it. I'm skeptical that's the reason they didn't use it unless it's a high-volume application. Like everything in IT, it depends. A high-volume app definitely needs attention to response and performance because employees will be wasting tons of hours if it's not. That's why primary applications should probably be desktop client-server applications, where it's easier to control the UI. But that's typically only roughly 1/4 of all apps used by an org. Something used only occasionally, such as for customers with special conditions, a somewhat sluggish web app is probably fine. If it's easy to make it snappy, great, but not everything is, due to our annoying web (non) standards[1]. If it takes 100 hours of programming to reduce 50 hours of UI waits over say a 10 year period, then the org doesn't benefit. 10 years is a good default rule of thumb duration for software lifetime. Your org may vary. Remember to include program maintenance, not just initial coding. In short, use the right tool for the job, and do some analysis math before starting. [1] My "favorite" rant is that web-standards suck for typical work-oriented productivity applications, and need a big overhaul or supplement. Nobody wants to solve this.
- mcguire 7y ago
  I'm sorry; are you saying that electronic patient care reports are not a "high volume application", that they should be "desktop client-server applications," or that the statements by the users about why they don't use the system should be disregarded?
  - tabtab 7y ago
    I don't have the usage & programming labor stats to make a definitive statement on that particular application including the size of the org using it. My main point was that "it depends" and should be subject to further tradeoff and business analysis rather than "X is always bad". A quarter-second lag does not sound like a significant problem to me, and may require a lot of IT funds to remove. Often such is only justified if it's a high-use application. Would you agree that 100 hours of extra programming to save 50 hours of data entry time is usually not worth it (all else being equal)? If so, let's start there and slice into further factors. Please don't give me bad scores for trying to be logical and rational, people! Resources are limited, orgs have to spend with care. Sure, it's nice job security for us IT people if orgs spend big bucks to make all apps snappy, but from a business and/or accounting standpoint, it could be the wrong decision. You view the world different when your money is on the line. If you know a way to make all apps cheap, good, AND snappy at the same time, let's here it! I'm all Vulcan ears. Note that one can make web apps snappy, but there are often maintenance and/or creation time tradeoffs for doing such. A few well-run shops do it well, but most shops are average-run.
mfer 7y ago
Something is missing in this conversation. Do the people who are creating the applications that deal with medical data have motivation to make it better or more useful? I've spoken with numerous people in my life who deal with these types of systems. Everyone complains. Fields for information are in unexpected places. There are too many things to click on. All of the people I've talked with agree on the same things. It's as if no UX people were involved. The experience doesn't fit the need quite right. What would motivate the makers of these things to improve on the situation? How are the contracts won? Do the people who have to use this stuff have a say in it? Do the hospitals and doctors offices measure stats to see what's working and what's not? This space is ripe for disruption simply based on user experience.
- Jwarder 7y ago
  I worked on EMS data entry software for a while (deepest apologies to any EMTs reading) and the big issue we ran into was needing to fulfill doctor/administrator pet projects to get a sale. The county wants to collect data on if a drowning incident happened at a pool without a locking gate. Now all services need to update their software to include a random checkbox. An EMT was caught without gloves and now the parent hospital wants EMTs to record what levels of PPE they wear on every run. The customer might get a grant if they can help track infectious diseases so now there is an extra box where the EMT can guess if the patient has the flu. In the abstract that is good data to want to know, but it ends up being more junk on the screen for the EMT to skip over while dealing with the patient or sitting in the hospital parking lot after a run.
  - JshWright 7y ago
    If I had a dollar for every time I swore at NEMSIS, I could quit my day job...
    - Jwarder 7y ago
      NEMSIS is ugly, but it is vastly easier to work with than HL7. That was an evil XML standard.
Kaiyou 7y ago
Always remember the Doherty-Threshold. "Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other." https://lawsofux.com/doherty-threshold https://lawsofux.com/doherty-threshold
grumpy8 7y ago
It's about trade-off. You improve performance at the cost of something else you're not working on. Without the context, it's hard to tell if that cost was justified. I.e. maybe there were 20 critical bugs and the team made the call that perf. was good-enough and it was better to stabilize the software. Most often than not, you can always improve performance and drawing the line is hard.
tibbon 7y ago
I saw this myself in an ambulance in the Boston area. The PCR system they were using was on some Toughbook-style computer, and I could tell that it was lagging and slow to input basic stuff on. Apparently whoever had put it together cared more about durability (important) than performance. Or maybe it worked great when it was deployed, but the newer software updates weren't built for such a slow machine. They used it; but it was like inputting a data on a slow ATM.
- TeMPOraL 7y ago
  Or maybe they made some stupid decisions like making each update query something over the Internet, which works fine when testing, but not when you're on the streets, in close proximity to a lot of other cellular Internet users.
arendtio 7y ago
My first tablet was kinda slow. At least slow enough that when it got too old, I wondered if I even wanted to buy another tablet, because I rarely used the first one. Then I bought a new one, which was faster and more responsive and my tablet usage completely changed ;-) So I can personally testify that performance is a most relevant part of the user experience.
JshWright 7y ago
Not sure where the author is from, but I'm not aware of any states that still allow paper PCRs. ePCRs are just a fact of life. I pretty much never bother opening the laptop until I'm at the hospital. There are a lot of reasons for that, but a laggy UX isn't really one of them (despite the fact that the UX is indeed super laggy on any ePCR I've ever used). Instead I use a pen and paper (or a pen and a strip of white medical tape on my thigh, for a more critical patient). The reason I don't bother is because the whole UI is just too much of a hassle. Not the application frontend, the whole thing. The laptop, the keyboard, etc. With a pen and paper I don't have to keep taking my gloves off and putting new ones on each time I need to switch from documenting something to caring for the patient (a pen is trivial to wipe down, or just toss if needed). With a pen and paper I can jot simple notes in a shorthand I'm familiar with, rather than having to navigate to the right page to enter the information I want to record at the moment. I know very few providers that bother touching the laptop prior to arrival at the hospital. Generally we write notes on paper, then bring the laptop into the ER and start typing while we we're waiting for a bed for our patient (it's not uncommon that this takes long enough to get the whole chart written). At my agency we have two hours from when we transfer care to when the chart has to be signed off and locked. I also chuckled at the suggestion that "0.1% of PCRs have errors that waste an hour of a doctor's time". In my experience 0.1% is pretty much how frequently the PCR gets reviewed at all in the ER, and anything important enough to spend an _hour_ on would have been mentioned up front during the transfer of care (nevermind the fact that an hour is an absurd amount of time for a doctor to be spending on a single patient).
- psychrometer 7y ago
  According to the about section of his blog, he is in Chicago. https://hillelwayne.com/about/ https://hillelwayne.com/about/
- seanmcdirmid 7y ago
  Wouldn’t a stylus/tablet interface provide the same benefits of a pen and paper solution for that requirement (well, you could wipe down the stylus, maybe chucking it is extreme)?
  - 7y ago
anderspitman 7y ago
My philosophical rule of thumb is that it is morally wrong for humans to ever wait on computers, period. It's an unattainable standard but results in much better software IMO.
Gene_Parmesan 7y ago
People who quote "premature optimization is etc." never provide the full quote. The full quote has a significant degree of highly important nuance. > "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." "Premature optimization is the root of all evil" is incomplete without the surrounding context, and people unfortunately take it to mean "never worry about how efficient your code is," which is not at all what Knuth intended.
- anaphor 7y ago
  Basically it can be summed up to "don't optimize until you've identified the critical paths"
  - defined 7y ago
    That’s oversimplifying it. Knuth was writing about micro-optimizations, like writing a section of code in assembly language to shave off some milliseconds from a critical section of code. What many people today mean by optimization is a far cry from that. Here’s a real-life example. Some code was super-slow and nobody could figure out why. It took only a minute to see the code was passing a string (in C++) by value, causing unnecessary copy construction and destruction (in a tight loop, to boot). Writing that code by passing a const reference in the first place is Good Coding 101, but many people might consider that “premature optimization”.
- deleted 7y ago
  [deleted]
aflam 7y ago
B
hinkley 7y ago
I have a theory on the dynamic being described, based on my experiences as a software developer. When you are juggling and prioritizing a list of tasks, they are occupying short term memory. If you can perform the current task from muscle memory, you don’t upset working memory. But as soon as you start having to think about it, and worse once you start editorializing in your head, things start to drop off. Worst case results of this phenomenon have occurred when you finish a hard task and you have to ask yourself, “what was I doing?/why was I doing this?” So you want your tools to be unobtrusive. People who love hand tools know this. Somehow we do not.
- desc 7y ago
  Indeed. "If I have to pay nearly as much or more attention to the use of this software than it saves me, it is by definition worthless." Intellisense in VS/Resharper went through a nice period a few years back where it was smart enough to match what was meant, fast enough that it didn't (usually) drop keypresses, and (crucially) stupid enough that typing the same thing twice would get the same results. Sadly, all of the above have been lost in the hail of features... Context sensitivity is not always a good thing in a tool. Muscle memory wins.
elevation 7y ago
I'm can't dispute that fast software is a desirable trait for users. I would love to spec low latencies into the requirements documents for my GUI projects. But from a business standpoint, UI latency requirements are a good way to sabotage a project. Slow solutions have a dramatic business advantage: using libraries, you can shave months off your delivery schedule by adding miliseconds to your UI delays. The months add up; so do the miliseconds. By using someone else's crufty libraries, you can write a calculator app over the weekend. Libraries will handle the double buffering for screen painting, unpacking fonts and rendering them into bitmaps, how to reflow text onto a screen, etc. It might take seconds for the app to load all it's assets and display the first user activity, but it was cheap to create, easy to iterate, and it gets the job done. These are hallmarks of a valuable startup engineering effort. But the development process for speedy applications is anathema to businesses of any size. You have to throw away Electron and hire systems engineers with knowledge of the entire platform. After some profiling, they may determine that the required speed is only possible once the system event handler has been replaced with a pared down routine, or when the framework's audio interface is bypassed so the sound card can be accessed through low-latency DMA mode. You have to repeat this for every platform you intend to support. You have to throw away the wheel that everyone else is using and pay to reinvent one that spins a little faster. To paraphrase Joel Spolsky's comment on rewriting software: are you sure you want to give that kind of a gift to your competitor? For most companies it isn't worth it. Are there exceptions? Yes: a motivated engineer like John Carmack may work months to eliminate another 3ms frame latency out of a VR headset simply because of personal passion. Google can amortize additional billions by wringing 100ms out of page load times by funding a browser project so complex that you also have to design a new build system for it. But if you're not Carmack and you're not Google, you probably can't afford to reinvent the wheel.
- deleted 7y ago
  [deleted]
- ikll 7y ago
  I don't agree that it's THAT hard. I used to work with WebForms and Cocoa (before iPhone) back when enterprise was completely allergic to web. Not only those tools were faster, but the development process itself was quicker and less traumatic than it is today. Interfaces were crude, but snappier. All grey, and users preferred using the return key to move between fields. And we could knock a calculator app in a few hours. The landscape was much more diverse too, a lot of women, and older folks (40/50+) coming from Fox Pro, Clipper or even COBOL (mostly on WebForms). I don't know what happened to those people when everyone moved to web tech. A lot of people my age moved to backend because they find HTML/CSS/JS too hard. Cocoa guys moved to iOS. I'm on frontend + iOS now. For the enterprise shops around here I know it all went to hell when both business AND developers started pushing modern multi-platform development: Qt, Java, Adobe, Cordova, you name it. Suddenly apps became crappier and a lot of people got pushed away from development because it was becoming too hard for them. After that everything became browser based. Mobile was weird for a while (too much Cordova), but it later settled on React Native. I know WebForms (and Interface Builder!) might look primitive and limited to today's developers, and I might be looking trough rose-colored glasses, but I remember when it was enough to build 90% of the apps people need, you don't need John Carmack or dealing with the audio buffer directly. Since this tech still exists, I can't see why that's not the case anymore :/
zentiggr 7y ago
Sounds like this PCR software should be structured around letting the operator enter information almost as freeform as possible, basically collecting timestamped notes that are reviewed and formalized afterward. UI up front can be very fast capture, with asynch layer to parse and formalize constructs, with a third stage of prefilling the final form (if paper layout needs to be maintained etc) and allowing very flexible revision. Last step would be archiving locally and then transmitting to whatever outside system.
- smacktoward 7y ago
  It'd be even better if, say, your insurance card had your basic medical info stored on it in some encrypted form, and then the EMTs could just scan the card and have half the form populated with accurate information automatically. Or if it just stored some kind of UID that the PCR system could use to pull that information from the insurance company's database.
api 7y ago
"Premature optimization is the root of all evil" is one of those programming sayings that's very often misunderstood. It does not mean that performance doesn't matter or that you shouldn't think about performance. What it means is two things: (1) It's usually a waste of time to tinker with small optimizations until you've made things work and until you've profiled. (2) Don't compromise your design or write unmaintainable code out of premature concern over performance. The second is the more important and subtile meaning. It means don't let concern for performance hobble your thinking about a problem.
yen223 7y ago
Sometimes you need to take a step back and consider the bigger picture. Is it really necessary to make an EMT fill out a 100-field form?
l0b0 7y ago
This sounds like a clear case of consultant software. The people building it won't be dogfooding the result - at most they'll be clicking around the UI on their powerful desktop machine and patting themselves on the back because it responds in less than half a second. The requirements will be vague, because getting performance requirements anywhere beyond stupidly vague "performant on modern hardware" or some shit requires real expertise in UI design and will cost real money to build, and UI designers won't be involved in the details until the contract is signed. "Premature optimization" in reality is a vacuous phrase, because premature anything is bad - it's right there in the word! (Insert joke here.) The problem is that most developers (myself included in many cases) are just not qualified to say when it is premature to optimize, because the requirements do not state anything meaningful about performance. If you think this is overly pessimistic, I would encourage running pretty much any Android app or opening any major website on a 2018 or older smartphone. It's pretty obvious developers don't know how to build software for the probably 50% or more of customers who don't buy a new top-of-the-line phone every year. As for performance guidelines, have a look at Jakob Nielsen's amazing evidence-backed UX guidelines such as Response Times: The 3 Important Limits[0]. The ones which should stick are that 0.1s feels instantaneous (probably not when using a scroll bar, but that's another matter) and 1s is the limit for not interrupting the user's flow of thought. In other words, if anything your program does takes more than 0.1s to respond to user input on the target hardware that should at least be acknowledged and prioritized (maybe at the end of the backlog, but at least then it's a known issue). [0] https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...
wawawiwa 7y ago
Why does this post have so many points? How is that article useful to most readers? I sometimes don't understand HN. Performance matters... the article talks about a case that most of us aren't confronted with. Beside, it concludes that in spite of paper being slower, it's still prefered, so how does that prove that "performance matters"?! Should an article be upvoted just because an article is about life and death and has a catchy (pretentiously) laconic title?
- Kaiyou 7y ago
  Paper is preferred because it has better performance than the software, which is the thing that people should think about. Writing software that can outperform paper shouldn't be hard to do, but apparently it is.
deleted 7y ago
[deleted]

401 points by MattGrommes 7y ago

I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are. Worse, I can use two different programs in Windows and one will be dog-slow compared to the other. I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there were for example programs having multiple version of the same library link into the code even while the program only used one library ever. Also the screen layout is runned thru a layout program/library that slows things down, the layout system is great when you are designing the system, but once you reach the point of final and fixed design there are faster ways to display it. on the other hand, management is too often cheap, and says "It works, don't it?" and do not want to pay for the extra coding that would make so much faster.

cogman10 7y ago
At least at my work, the issue is twofold. First, nobody measures performance. If they do, it is often done poorly (without using performance tools) Second, when performance is a problem, everyone guesses on the cause. Remember how they don't measure? Well, they also will say things like "this is probably slow because of X" where X is the database, the network, a method they hate, etc. Performance analysis requires accurate measurement.
- leeoniya 7y ago
  this sounds terrifying. thankfully at my work nothing goes into production without a performance eval measured at least by Lighthouse & webpagetest on Fast 3G/2015 mobile/chrome. it's nice to be able to dictate these requirements ;)
pjc50 7y ago
Almost all of this stuff is caused by doing blocking IO on the UI thread. Unfortunately that becomes harder and harder to avoid doing by accident. And if part of the UI code or data gets paged out, there's a colossal hit to responsiveness.
Crinus 7y ago
The Windows vs Haiku case you describe is mainly a difference in terms of development culture. In Windows you can get similar fast performance and responsiveness by using the native GUI functionality, but most desktop applications nowadays use toolkits like Qt (at best) or Electron (at worst) that reimplement a ton of functionality that the OS itself already provides and treat it as something different than what it really is. On the other hand in Haiku everything uses the native Haiku APIs. But from what i've seen ever since Qt and Java were ported to Haiku, a bunch of applications started relying on those to run on it instead of using the native APIs (which IMO defeats the entire point of Haiku). Haiku does use a lot of prewritten libraries BTW, they're just hidden behind the scenes and shared among applications instead of each one bringing their own copy.
gameswithgo 7y ago
It isn't just management. Most software ecosystems (Rust, C, c++ excluded) discourage any thinking about or tinkering with performance knowledge. You see evidence of this on stackoverflow questions, questions on reddit and twitter. Young people or new programmers curious about the fastest way to do things are always lectured about how this is not good to do. It is quite unfortunate because building some experience for how to do things fast is very useful. It isn't always correct to optimize the hell out of things, of course, but we should encourage the curiosity behind it, so that more of us have the tools to do it when it is correct to do so.
- mark-r 7y ago
  I have often found that doing things efficiently isn't really harder than doing them slow. So why not aim for software that's reasonably performant from the start? Sure you can micro-optimize to get every last nanosecond, but that's not what I'm talking about.
kitsunesoba 7y ago
The “leaning tower of abstractions” problem absolutely should be receiving more attention than it has been, because otherwise it’s only going to get worse. I don’t know what a fix looks like exactly, but something has to change.
jodrellblank 7y ago
Amiga at least, older computers were more responsive because they did less - directly attached video and keyboard hardware, no USB, no compositing video drivers, less font smoothing, and so on. See Dan Luu's analysis here: https://danluu.com/input-lag/ https://danluu.com/input-lag/ and here https://danluu.com/keyboard-latency/ https://danluu.com/keyboard-latency/ > Moreover, a modern computer with one of the slower keyboards attached can’t possibly be as responsive as a quick machine from the 70s or 80s because the keyboard alone is slower than the entire response pipeline of some older computers. Haiku (BeOS) was always promoted on its native multithreading and responsive UI, with early demonstrations showing windows being dragged around while playing video, IIRC, it's impressive that it still holds to that. But it also says a bit about what software people pay for and keep using - if sluggish Windows software has thrived, and BeOS crashed and burned. And then on Windows and Linux, light fast software gives way to bloaty huge sluggish software left and right.

ChrisSD 7y ago

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

ziddoap 7y ago
Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?
- ChrisSD 7y ago
  Because that's literally the complaint as given. If the UI had reacted "instantly" it would be more user friendly. Even if the performance of the (non UI) code was slower. EDIT: Or to put it another way: "perceived performance can be more important than actual performance".
  - juliangoldsmith 7y ago
    Responsiveness is a result of adequate performance. The dropdowns that the article refers to are probably populated by a database, as opposed to being static. It doesn't matter if the dropdown opens instantly, what matters is that the information it contains is available.
- 0xDEFC0DE 7y ago
  My take is that responsiveness has a cap of speed that’s pinned to human perception. Once you get here you can stop worrying about needing more. Performance does work as fast as possible regardless. You always want more but you’re capped by the system, hardware, and algorithms and not human perception. Feels like I’m splitting hairs though
  - viraptor 7y ago

agentultra 7y ago

I believe performance does matter and should factor into the design of a system. There is an ISO guidelines on software system requirements and specifications that has a section for performance requirements. It does matter even for banal, non-critical or non-life-threatening software systems. Another often-overlooked requirement: environment. Does the human using your software system have to pay attention to more important situations around them? Is the environment they're using your software in noisy, stressful, dangerous or dirty? Should you expect frequent wireless interference or degraded wireless performance? Reading the ISO specs are pretty boring, so is the SWEBOK guide, but it's rather interesting to think about software in terms of the whole system and not as an artifact unto itself.

nickpsecurity 7y ago
You'll probably like Nancy Leveson's model and work if you haven't seen it: http://sunnyday.mit.edu/accidents/safetyscience-single.pdf http://sunnyday.mit.edu/accidents/safetyscience-single.pdf http://sunnyday.mit.edu/ http://sunnyday.mit.edu/
defined 7y ago
I’m with you, but good luck getting some scrum shop to include enough detail to achieve this.

whistlerbrk 7y ago

As a former EMT and someone who built their own software to create run reports, I'm a bit skeptical as to that being the only reason. Paper can be edited, even after the point at which you given a carbon copy to a hospital, if you're friendly enough. This probably doesn't happen often or at all but there is a psychological safety there. People make small mistakes all the time on the ambulance in the rush to get them to the ER. We live in an extremely litigious society.

ben509 7y ago
That's a good insight. Never dealt with any medical stuff, but I dealt with paperwork in the military as it was going through a (long painful) transition to electronic documents back in the '00s. And I don't think it's just that society is litigous, but that databases actually (mostly?) work in terms of enforcing the rules you give them. One anecdote of how things changed was that you used to be able to arrive on post, and if you didn't like your orders, talk to a sergeant major of another unit and quietly get your orders changed, which no doubt drove PERSCOM crazy. When things were done with paper, there was a certain degree of flexibility in the rules that gave people some amount of local autonomy. When those rules are enforced by a computer, there's much less possibility of someone being able to override the rules when it makes sense. Normal human social interaction tends to create unwritten rules that are simply more flexible and realistic than the rules we're willing or able to write down.
- abraae 7y ago
  We have a platform that amongst other things automates filling in a fairly complex government form, including online signature. We did a demo the other day to a large new customer. I learned that when they filled in the existing paper form, they didn't just sign it, they also stamped in the signature box with a little rubber stamp that "signed on behalf of the CEO". It wasn't immediately clear whether anyone handling the form was looking for that stamp, nor what they did when they saw it. As a result, it's not clear to us at this stage whether our pdf generation now needs a new feature to allow a user-uploadable image file to be imprinted over the form. That's the sort of thing you get with the joyous "flexibility" of paper.

shay_ker 7y ago

Did that quarter-second lag kill anyone? Was there someone who wouldn’t have died if the ePCR was just a little bit faster, fast enough to be usable? And the people who built it: did they ask the same questions? Did they say “premature optimization is bad” and not think about performance until it was too late? Did they decide another feature for the client was more important than making the existing features faster? Did they even think about performance at all? This seems like a lot of imagining of scenarios that may or may not have happened. Perhaps another way of looking at this is - did the company hired to build this actually care whether EMTs used their software, or were they looking to get a paycheck? So many health tech firms fall in the latter bucket. Such is the reality of the business - with huge enterprise sales funnels and hospital networks that don't understand the value of UX & great product (and caring a lot about their bottom line), this result isn't unexpected.

JshWright 7y ago
If someone is sick enough that a "quarter second" matters, there's zero chance the tablet is out in the first place. In reality if a quarter second is enough to kill someone, they're gonna die anyway...
- bananocurrency 7y ago
  I feel the same about my EKG. What's a quarter second when it comes to measuring a heart? Who cares about precision.
  - JshWright 7y ago
    A quarter of a second in measurement resolution of an EKG is huge. An extra quarter of a second interpreting or documenting that EKG couldn't be any more meaningless.

Ensorceled 7y ago

When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, testing for drift in beta testing, etc. In our testing, 10 seconds was the absolute maximum time that a surgeon could "idle" and stay on task in surgery. In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration. The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.

phkahler 7y ago
>> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays. IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.
- penagwin 7y ago
  I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.
  - jblow 7y ago
    The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system. It's just that modern software is garbage. That's all.

rossdavidh 7y ago

So, interesting and all, but it ignores the main reason for the advice to build it first, then optimize for performance, which is that if you build everything for performance from the beginning, you end up with a lot of code that is optimizing for performance of something that isn't the bottleneck. In other words, performance that doesn't show up in the user's experience, because something else is the main delay. Now, if all that meant was that the programmer has to do some more work, and you aren't worried about paying more for the software, this may not matter, but that is far from the only (or even most important) result of optimizing everything for performance. Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy. For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This can result in big improvements to software performance if done in the places which are the current limiting step, but now you have to make sure you invalidate the cache correctly. In particular, if you don't, you get stale values in the cache, which is to say false data. If you make a system with cacheing all over the place, it will be very hard to make changes correctly, which means sometimes they will get made incorrectly. In mission-critical systems, this is even less acceptable than elsewhere. It's not just "I don't feel like optimizing". More often, it's the cost of optimizing is not worth the benefit, for this particular part of the code. How do you know what spots in the code it's worth it? You don't optimize, at first, and then see which two or three spots in the system are rate-limiting.

phkahler 7y ago
>> For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This made me cringe. This is filling out a form. It could conceivably be a single record (or small set) in memory that gets committed/updated somewhere else in the background. Overly complicated solutions for simple problems are one of the primary things that kills performance. You don't have to optimize everything for performance, you just have to realize it's a primary feature and avoid doing anything that kills it. We carry super computers in our pockets, you don't have to write complex game code to get performance these days, just don't write shitty things.

jancsika 7y ago

Welcome to the world of soft realtime applications. Sounds like this one is just so bad that a) the designers didn't realize that was what they were designing and b) consequently it failed to meet any of its deadlines in the UI domain. One detail I've noticed is that even if you do a shitty job of hitting the deadlines, users will often find workarounds. As long as a critical mass of features respond consistently within the deadlines, users will fiddle around to make the rest work-- even if you tell them directly that it isn't possible. Say the dropdown menus here performed fast enough, but going to the "next page" required a bunch of DOM mutation or something that grinds to a halt for two seconds. I'd bet EMTs would have trained themselves to do branch prediction-- hit the button to change pages before setting it down, hit it again based on what the patient is communicating to the other EMT, and so forth. I've seen users do weirder stuff. The fact that they discarded it altogether tells you how bad the UI was.

wickerman 7y ago

I don't think the word performance is key, but rather /user experience/.

tabtab 7y ago

Quote: It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it. I'm skeptical that's the reason they didn't use it unless it's a high-volume application. Like everything in IT, it depends. A high-volume app definitely needs attention to response and performance because employees will be wasting tons of hours if it's not. That's why primary applications should probably be desktop client-server applications, where it's easier to control the UI. But that's typically only roughly 1/4 of all apps used by an org. Something used only occasionally, such as for customers with special conditions, a somewhat sluggish web app is probably fine. If it's easy to make it snappy, great, but not everything is, due to our annoying web (non) standards[1]. If it takes 100 hours of programming to reduce 50 hours of UI waits over say a 10 year period, then the org doesn't benefit. 10 years is a good default rule of thumb duration for software lifetime. Your org may vary. Remember to include program maintenance, not just initial coding. In short, use the right tool for the job, and do some analysis math before starting. [1] My "favorite" rant is that web-standards suck for typical work-oriented productivity applications, and need a big overhaul or supplement. Nobody wants to solve this.

mcguire 7y ago
I'm sorry; are you saying that electronic patient care reports are not a "high volume application", that they should be "desktop client-server applications," or that the statements by the users about why they don't use the system should be disregarded?
- tabtab 7y ago
  I don't have the usage & programming labor stats to make a definitive statement on that particular application including the size of the org using it. My main point was that "it depends" and should be subject to further tradeoff and business analysis rather than "X is always bad". A quarter-second lag does not sound like a significant problem to me, and may require a lot of IT funds to remove. Often such is only justified if it's a high-use application. Would you agree that 100 hours of extra programming to save 50 hours of data entry time is usually not worth it (all else being equal)? If so, let's start there and slice into further factors. Please don't give me bad scores for trying to be logical and rational, people! Resources are limited, orgs have to spend with care. Sure, it's nice job security for us IT people if orgs spend big bucks to make all apps snappy, but from a business and/or accounting standpoint, it could be the wrong decision. You view the world different when your money is on the line. If you know a way to make all apps cheap, good, AND snappy at the same time, let's here it! I'm all Vulcan ears. Note that one can make web apps snappy, but there are often maintenance and/or creation time tradeoffs for doing such. A few well-run shops do it well, but most shops are average-run.

mfer 7y ago

Something is missing in this conversation. Do the people who are creating the applications that deal with medical data have motivation to make it better or more useful? I've spoken with numerous people in my life who deal with these types of systems. Everyone complains. Fields for information are in unexpected places. There are too many things to click on. All of the people I've talked with agree on the same things. It's as if no UX people were involved. The experience doesn't fit the need quite right. What would motivate the makers of these things to improve on the situation? How are the contracts won? Do the people who have to use this stuff have a say in it? Do the hospitals and doctors offices measure stats to see what's working and what's not? This space is ripe for disruption simply based on user experience.

Jwarder 7y ago
I worked on EMS data entry software for a while (deepest apologies to any EMTs reading) and the big issue we ran into was needing to fulfill doctor/administrator pet projects to get a sale. The county wants to collect data on if a drowning incident happened at a pool without a locking gate. Now all services need to update their software to include a random checkbox. An EMT was caught without gloves and now the parent hospital wants EMTs to record what levels of PPE they wear on every run. The customer might get a grant if they can help track infectious diseases so now there is an extra box where the EMT can guess if the patient has the flu. In the abstract that is good data to want to know, but it ends up being more junk on the screen for the EMT to skip over while dealing with the patient or sitting in the hospital parking lot after a run.
- JshWright 7y ago
  If I had a dollar for every time I swore at NEMSIS, I could quit my day job...
  - Jwarder 7y ago
    NEMSIS is ugly, but it is vastly easier to work with than HL7. That was an evil XML standard.

Kaiyou 7y ago

Always remember the Doherty-Threshold. "Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other." https://lawsofux.com/doherty-threshold https://lawsofux.com/doherty-threshold

grumpy8 7y ago

It's about trade-off. You improve performance at the cost of something else you're not working on. Without the context, it's hard to tell if that cost was justified. I.e. maybe there were 20 critical bugs and the team made the call that perf. was good-enough and it was better to stabilize the software. Most often than not, you can always improve performance and drawing the line is hard.

tibbon 7y ago

I saw this myself in an ambulance in the Boston area. The PCR system they were using was on some Toughbook-style computer, and I could tell that it was lagging and slow to input basic stuff on. Apparently whoever had put it together cared more about durability (important) than performance. Or maybe it worked great when it was deployed, but the newer software updates weren't built for such a slow machine. They used it; but it was like inputting a data on a slow ATM.

TeMPOraL 7y ago
Or maybe they made some stupid decisions like making each update query something over the Internet, which works fine when testing, but not when you're on the streets, in close proximity to a lot of other cellular Internet users.

arendtio 7y ago

My first tablet was kinda slow. At least slow enough that when it got too old, I wondered if I even wanted to buy another tablet, because I rarely used the first one. Then I bought a new one, which was faster and more responsive and my tablet usage completely changed ;-) So I can personally testify that performance is a most relevant part of the user experience.

JshWright 7y ago

Not sure where the author is from, but I'm not aware of any states that still allow paper PCRs. ePCRs are just a fact of life. I pretty much never bother opening the laptop until I'm at the hospital. There are a lot of reasons for that, but a laggy UX isn't really one of them (despite the fact that the UX is indeed super laggy on any ePCR I've ever used). Instead I use a pen and paper (or a pen and a strip of white medical tape on my thigh, for a more critical patient). The reason I don't bother is because the whole UI is just too much of a hassle. Not the application frontend, the whole thing. The laptop, the keyboard, etc. With a pen and paper I don't have to keep taking my gloves off and putting new ones on each time I need to switch from documenting something to caring for the patient (a pen is trivial to wipe down, or just toss if needed). With a pen and paper I can jot simple notes in a shorthand I'm familiar with, rather than having to navigate to the right page to enter the information I want to record at the moment. I know very few providers that bother touching the laptop prior to arrival at the hospital. Generally we write notes on paper, then bring the laptop into the ER and start typing while we we're waiting for a bed for our patient (it's not uncommon that this takes long enough to get the whole chart written). At my agency we have two hours from when we transfer care to when the chart has to be signed off and locked. I also chuckled at the suggestion that "0.1% of PCRs have errors that waste an hour of a doctor's time". In my experience 0.1% is pretty much how frequently the PCR gets reviewed at all in the ER, and anything important enough to spend an _hour_ on would have been mentioned up front during the transfer of care (nevermind the fact that an hour is an absurd amount of time for a doctor to be spending on a single patient).

psychrometer 7y ago
According to the about section of his blog, he is in Chicago. https://hillelwayne.com/about/ https://hillelwayne.com/about/
seanmcdirmid 7y ago
Wouldn’t a stylus/tablet interface provide the same benefits of a pen and paper solution for that requirement (well, you could wipe down the stylus, maybe chucking it is extreme)?
- 7y ago

anderspitman 7y ago

My philosophical rule of thumb is that it is morally wrong for humans to ever wait on computers, period. It's an unattainable standard but results in much better software IMO.

Gene_Parmesan 7y ago

People who quote "premature optimization is etc." never provide the full quote. The full quote has a significant degree of highly important nuance. > "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." "Premature optimization is the root of all evil" is incomplete without the surrounding context, and people unfortunately take it to mean "never worry about how efficient your code is," which is not at all what Knuth intended.

anaphor 7y ago
Basically it can be summed up to "don't optimize until you've identified the critical paths"
- defined 7y ago
  That’s oversimplifying it. Knuth was writing about micro-optimizations, like writing a section of code in assembly language to shave off some milliseconds from a critical section of code. What many people today mean by optimization is a far cry from that. Here’s a real-life example. Some code was super-slow and nobody could figure out why. It took only a minute to see the code was passing a string (in C++) by value, causing unnecessary copy construction and destruction (in a tight loop, to boot). Writing that code by passing a const reference in the first place is Good Coding 101, but many people might consider that “premature optimization”.
deleted 7y ago
[deleted]

aflam 7y ago

hinkley 7y ago

I have a theory on the dynamic being described, based on my experiences as a software developer. When you are juggling and prioritizing a list of tasks, they are occupying short term memory. If you can perform the current task from muscle memory, you don’t upset working memory. But as soon as you start having to think about it, and worse once you start editorializing in your head, things start to drop off. Worst case results of this phenomenon have occurred when you finish a hard task and you have to ask yourself, “what was I doing?/why was I doing this?” So you want your tools to be unobtrusive. People who love hand tools know this. Somehow we do not.

desc 7y ago
Indeed. "If I have to pay nearly as much or more attention to the use of this software than it saves me, it is by definition worthless." Intellisense in VS/Resharper went through a nice period a few years back where it was smart enough to match what was meant, fast enough that it didn't (usually) drop keypresses, and (crucially) stupid enough that typing the same thing twice would get the same results. Sadly, all of the above have been lost in the hail of features... Context sensitivity is not always a good thing in a tool. Muscle memory wins.

elevation 7y ago

I'm can't dispute that fast software is a desirable trait for users. I would love to spec low latencies into the requirements documents for my GUI projects. But from a business standpoint, UI latency requirements are a good way to sabotage a project. Slow solutions have a dramatic business advantage: using libraries, you can shave months off your delivery schedule by adding miliseconds to your UI delays. The months add up; so do the miliseconds. By using someone else's crufty libraries, you can write a calculator app over the weekend. Libraries will handle the double buffering for screen painting, unpacking fonts and rendering them into bitmaps, how to reflow text onto a screen, etc. It might take seconds for the app to load all it's assets and display the first user activity, but it was cheap to create, easy to iterate, and it gets the job done. These are hallmarks of a valuable startup engineering effort. But the development process for speedy applications is anathema to businesses of any size. You have to throw away Electron and hire systems engineers with knowledge of the entire platform. After some profiling, they may determine that the required speed is only possible once the system event handler has been replaced with a pared down routine, or when the framework's audio interface is bypassed so the sound card can be accessed through low-latency DMA mode. You have to repeat this for every platform you intend to support. You have to throw away the wheel that everyone else is using and pay to reinvent one that spins a little faster. To paraphrase Joel Spolsky's comment on rewriting software: are you sure you want to give that kind of a gift to your competitor? For most companies it isn't worth it. Are there exceptions? Yes: a motivated engineer like John Carmack may work months to eliminate another 3ms frame latency out of a VR headset simply because of personal passion. Google can amortize additional billions by wringing 100ms out of page load times by funding a browser project so complex that you also have to design a new build system for it. But if you're not Carmack and you're not Google, you probably can't afford to reinvent the wheel.

deleted 7y ago
[deleted]
ikll 7y ago
I don't agree that it's THAT hard. I used to work with WebForms and Cocoa (before iPhone) back when enterprise was completely allergic to web. Not only those tools were faster, but the development process itself was quicker and less traumatic than it is today. Interfaces were crude, but snappier. All grey, and users preferred using the return key to move between fields. And we could knock a calculator app in a few hours. The landscape was much more diverse too, a lot of women, and older folks (40/50+) coming from Fox Pro, Clipper or even COBOL (mostly on WebForms). I don't know what happened to those people when everyone moved to web tech. A lot of people my age moved to backend because they find HTML/CSS/JS too hard. Cocoa guys moved to iOS. I'm on frontend + iOS now. For the enterprise shops around here I know it all went to hell when both business AND developers started pushing modern multi-platform development: Qt, Java, Adobe, Cordova, you name it. Suddenly apps became crappier and a lot of people got pushed away from development because it was becoming too hard for them. After that everything became browser based. Mobile was weird for a while (too much Cordova), but it later settled on React Native. I know WebForms (and Interface Builder!) might look primitive and limited to today's developers, and I might be looking trough rose-colored glasses, but I remember when it was enough to build 90% of the apps people need, you don't need John Carmack or dealing with the audio buffer directly. Since this tech still exists, I can't see why that's not the case anymore :/

zentiggr 7y ago

Sounds like this PCR software should be structured around letting the operator enter information almost as freeform as possible, basically collecting timestamped notes that are reviewed and formalized afterward. UI up front can be very fast capture, with asynch layer to parse and formalize constructs, with a third stage of prefilling the final form (if paper layout needs to be maintained etc) and allowing very flexible revision. Last step would be archiving locally and then transmitting to whatever outside system.

smacktoward 7y ago
It'd be even better if, say, your insurance card had your basic medical info stored on it in some encrypted form, and then the EMTs could just scan the card and have half the form populated with accurate information automatically. Or if it just stored some kind of UID that the PCR system could use to pull that information from the insurance company's database.

api 7y ago

"Premature optimization is the root of all evil" is one of those programming sayings that's very often misunderstood. It does not mean that performance doesn't matter or that you shouldn't think about performance. What it means is two things: (1) It's usually a waste of time to tinker with small optimizations until you've made things work and until you've profiled. (2) Don't compromise your design or write unmaintainable code out of premature concern over performance. The second is the more important and subtile meaning. It means don't let concern for performance hobble your thinking about a problem.

yen223 7y ago

Sometimes you need to take a step back and consider the bigger picture. Is it really necessary to make an EMT fill out a 100-field form?

l0b0 7y ago

This sounds like a clear case of consultant software. The people building it won't be dogfooding the result - at most they'll be clicking around the UI on their powerful desktop machine and patting themselves on the back because it responds in less than half a second. The requirements will be vague, because getting performance requirements anywhere beyond stupidly vague "performant on modern hardware" or some shit requires real expertise in UI design and will cost real money to build, and UI designers won't be involved in the details until the contract is signed. "Premature optimization" in reality is a vacuous phrase, because premature anything is bad - it's right there in the word! (Insert joke here.) The problem is that most developers (myself included in many cases) are just not qualified to say when it is premature to optimize, because the requirements do not state anything meaningful about performance. If you think this is overly pessimistic, I would encourage running pretty much any Android app or opening any major website on a 2018 or older smartphone. It's pretty obvious developers don't know how to build software for the probably 50% or more of customers who don't buy a new top-of-the-line phone every year. As for performance guidelines, have a look at Jakob Nielsen's amazing evidence-backed UX guidelines such as Response Times: The 3 Important Limits[0]. The ones which should stick are that 0.1s feels instantaneous (probably not when using a scroll bar, but that's another matter) and 1s is the limit for not interrupting the user's flow of thought. In other words, if anything your program does takes more than 0.1s to respond to user input on the target hardware that should at least be acknowledged and prioritized (maybe at the end of the backlog, but at least then it's a known issue). [0] https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-...

wawawiwa 7y ago

Why does this post have so many points? How is that article useful to most readers? I sometimes don't understand HN. Performance matters... the article talks about a case that most of us aren't confronted with. Beside, it concludes that in spite of paper being slower, it's still prefered, so how does that prove that "performance matters"?! Should an article be upvoted just because an article is about life and death and has a catchy (pretentiously) laconic title?

Kaiyou 7y ago
Paper is preferred because it has better performance than the software, which is the thing that people should think about. Writing software that can outperform paper shouldn't be hard to do, but apparently it is.

deleted 7y ago

[deleted]