Performance Matters (2019)

But, software that ignores, delays or discards user inputs? Absolutely F*$#ing Unacceptable.

Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it.

If you write UI software, you have one job. To utterly cherish user input, painstakingly preserve it, and lovingly and promptly provide user output. That's it. Almost anything else is optional, and can be forgiven.

Story time: I got hit by performance these very days. The app I'm developing for one of my clients has to process images from an USB camera. Under my development everything is dandy. Works like a charm, images gets processed and when the user hits the on-screen button that image gets stored in database as part of the entire process. Neath, yeah?

Well, it turns out my client is using a cheap from last decade tablet (I'm a purist so this decade will end on 31st Dec 2020) that due to processing 30 frames each second from USB camera, has little time for actual GUI responsiveness. And the app feels sluggish, with 1 second delay between my tap and the combobox firing up. Turns out, it didn't need to actually process all those 30 frames each second. On per second will suffice, hence I've implemented to only process on frame every second. More than enough for customer's needs and now the app is also flying on that old hardware.

My 2 cents.

I've once worked on a system that was objectively slow. Some actions would take seconds to complete. It's not like people would refuse the use the system, it was the only way to do their jobs. The public had no choice, either.

Initially, I didn't think it was such a big deal. Yes it was a bit slow, but nothing _terrible_ and why did it matter, since there were so many other procedures that took way longer than the software step. It was a government facility, lots of red tape. Surely optimizing some of the paper processes would be more beneficial.

But we optimized it anyway. Not because the UI was slow(which we didn't even measure directly), but because it was slow for a reason - backend processes were taking time, and resources. If we could optimize, we thought, we would save resources (and also increase the runway until we had to expand again, buy hardware and the like).

First round of optimization was completed. Lots of low hanging fruits(many database-related). Testing indicated that the backend would be faster by almost an order of magnitude. Deployed.

THE SYSTEM BECAME SLOWER.

How was that possible? Maybe we had missed something. We found more bottlenecks, optimized those. Deployed again.

Everything is slow again. What's happening?!

We went to the 'field' - as in, talked to the users. Well, this is what we discovered: we saw the backend working harder - because the users were more productive! Instead of staying after the facilities were closed to the public and then catching up on whatever paperwork they were unable to enter in the system, they could process everything almost as fast as people came in. Which means that they could go home early.

What we saw as "the system being slow again" was due to bad metrics - we were watching backend load, not UI response times. Because, admittedly, that didn't bother us directly. Not until we talked to the poor souls that had to use the system. Lots of async processes got triggered and queues filled up, but it didn't really matter to the users, as long as the UI said things were submitted and they could move on.

After that, we optimized the heck out of all the UI interactions we could find.