Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Matters

hillelwayne.com

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Performance Matters

#111

Post by JshWright »

joshstrange wrote: post #106
JshWright wrote: post #54

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 m…

My boyfriend is a nurse and said a very similar thing. He said he very rarely looks at a PCR as everything important is conveyed verbally when the handoff from EMT->Hospital.

I'm glad I omitted the ER nurse targeted snark in that case... ;)

Re: Performance Matters

#112

Post by jihoon796 »

mfer wrote: post #33

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.…

Like qudat said, the level of rules and regulations required to enter the market are indeed pretty high, but I don't think they are insurmountable. And industry connections certainly do help in getting contracts, but people will generally listen if you have good ideas.

The people making the purchasing decisions are almost always pretty removed from day-to-day usage of clinical software (and the bigger the company, the more true this is).

But how will you present to them that your new product is "better" than that of the incumbent's? You can say, "our product can do X feature 10x better than another product", but if they reply with "unless your product has dark mode for a select number of physicians who live in WA and NY state, it's going to be a no-go. We already have another quote from someone else who will do this for us", what are you going to do? You may resist at first, but in order to win the business, you too will likely repeat this process ad-nauseum, until your "MVP" becomes just a "VP".

These decision-makers are also cautious about "new" technology (and rightly so, for the most part). Since if something does go wrong with patient data, it is considered catastrophic - and who will be to blame then?

Re: Performance Matters

#113

Post by wmf »

penagwin wrote: post #37
phkahler wrote: post #30

Earlier quoted context omitted.

>> 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.

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…

many embedded interfaces/controllers don't have very fast processors/microcontrollers

I'm reminded of the discussion the other day about military procurement ignoring software. Prototype the UI first, then choose a processor that's fast enough.

Re: Performance Matters

#114

Post by ikll »

elevation wrote: post #83

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 a…

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 :/

Re: Performance Matters

#115

Post by ISL »

seanmcdirmid wrote: post #103
filoleg wrote: post #101

Earlier quoted context omitted.

>a stylus will just get lost within the first day Extremely relatable. Someone needs to come up with a stylus that is permanently attached to a laptop using a wire or some other sort of contraption, similar to writing pads with permanently attached pens. The slot (hole) for the stylus should still stay, so that it can be packed up/stored neatly. The main reason it was not done yet, my guess, is because of the danglin…

Or just use a resistive digitizer above the screen and make anything with a tip a stylus, so they can be disposable and replaceable like pens.

Or make capacitive-capable styli disposable/replaceable like pens.

Re: Performance Matters

#116

Post by unrealhoang »

TeMPOraL wrote: post #44
rossdavidh wrote: post #22

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…

> Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy. I'm gonna repost a chart I made previously[0][1]. Spectrum of performance: LO |---*-------*--------*------------*-------| HI ^ ^ ^ ^ | | | |_root of all evil if premature | | |_you should be here | |_you can be here if you don't do stupid things |_you are here Tricks like denormalizing y…

Usually, it's more like this:

  LO |---*------------------*----*--*-| HI
         ^                  ^    ^  ^
         |                  |    |  |_root of all evil if premature
         |                  |    |_you should be here
         |                  |_you can be here if you don't do stupid things
         |_you are here

Re: Performance Matters

#117

Post by wpietri »

Ensorceled wrote: post #21

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 cogniti…

I don't know how optimistic I'd be about the whole industry. I'd suspect medical devices are way more disciplined than EHR apps.

A friend's sister is a doctor. We happened to be visiting her hospital the week they were rolling out a new system. If if I recall rightly, her hospital was part of a multi-hospital company, and they were developing it in house. The developers were in some location distant to the hospital, and my doctor pal had never met anybody who worked on it.

From my perspective, the thing was a disaster. Not only was it laggy as hell, but the interface was dumbfoundingly bad. For a doctor to prescribe something for a patient, the would have to pick the medication name from an absurdly long drop-down. Then they could type in a quantity and pick a unit from a pulldown that had mcg, mg, g, and kg choices. Once that was entered, it would show up on the reports nurses would use to give medication. However, they didn't have the field sizing right on the reports, so 100 mg would turn into 10 mg. It was only nurse experience that kept people from getting dangerously wrong doses of their medication.

The whole thing was hot garbage of exactly the sort made in a big waterfall process by developers who never met the users and never saw them in action. I'm sure every bit of it was technically to spec, but I'd be amazed if nobody died from it.

Re: Performance Matters

#118

Post by beachy »

ben509 wrote: post #70
whistlerbrk wrote: post #10

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…

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 pos…

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.

Re: Performance Matters

#119

Post by girvo »

seanmcdirmid wrote: post #103
filoleg wrote: post #101

Earlier quoted context omitted.

>a stylus will just get lost within the first day Extremely relatable. Someone needs to come up with a stylus that is permanently attached to a laptop using a wire or some other sort of contraption, similar to writing pads with permanently attached pens. The slot (hole) for the stylus should still stay, so that it can be packed up/stored neatly. The main reason it was not done yet, my guess, is because of the danglin…

Or just use a resistive digitizer above the screen and make anything with a tip a stylus, so they can be disposable and replaceable like pens.

I could've sworn that the Panasonic laptops that I've seen EMTs use here in Australia had exactly that. Though I've never been in the best shape when I'm in the back of an ambulance lol

Re: Performance Matters

#120

Post by nickpsecurity »

agentultra wrote: post #6

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 imp…

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/

Post reply on HN