I'm torn between two axis. The first is being user oriented. Think about the problems from their perspective. Make sure you are always working on something that improves value. The second is that good software is often fast software.
A hard case to make is holding to a max of 500ms latencty at 99p will increase the value to your users. I've found that trying to make the case is important though.
The reality of the situoation is that it depends. It's always contextual.
I've got two articles that help contextualize performance.
The first is “Performance Matters” by Hillel Wayne. He writes about EMTs and a report they have to fill out about what they did for a patient called a Patient Care Report (PCR). Apparently about 30 million are filled out each year:
At that scale, time and life are interchangeable. Every minute writing and filing a PCR is a minute not spent on actual treatment. If 0.1% of PCRs have mistakes that waste an hour of a doctor’s time, that’s 30,000 doctor-hours not spent on other patients. It’s a factor so grand and diffuse we can’t see it in motion. We can’t think in those terms.
I appreciate that Wayne contextualizes performance. It's important that we improve the perfomance of EMTs because they can save more human life in aggregate. The software they use must meet certain performance otherwise humans will do what we do best - follow the path of least resistance.
I know the inevitable remark - but, most of us aren't dealing with “human lives”. And, yea, most of us won't cause harm in our users lives because our software doesn't work exactly right.
Hold on to that thought for a moment though.
Here is another essay from Craig Mod, “Fast Software, the Best Software".
To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
I think Mod makes an elegant argument that peformance is one of the most valueable invisible requirements for good software. It's required for software that isn't just dealt with, but appreciated.
It feels — intuitively — that software (beyond core functionality) should aim for speed. Speed as a proxy for efficiency.
Speed as a goal. That's an interesting idea and one that I think brings this continumum full circle.
I am a human. I work on software. I work with whole orgaizations of people. We are accountable for it's operations. When we don't care about performance and corectness there is an inevitable degredation in quality, like entropy. This kind of degredation starts small, but can grow to an uncontrolable mess. Which can lead to stress and pain for the humans in the loop. In the best case, people you care about will be so stressed that they leave your organization. Leading to futher degratation.
Unless, of course, you continually mind the quality. Maybe, if performance is a perpetualy goal, you can speed things up a little faster then things slow down.
I measure latency always, I keep an eye on it and I attempt to remediate performance issues overtime. It does not mean that I am infelexible buisness partner though. I always try and make the case for performance. I keep it top of mind.
It's my perptual partner when building software.
To close it out, I think this software aphorism about sums it up.
“Make it work. Make it right. Make It fast” 1