Skip to main content

Why is Performance Important?

I often lament the transition from desktop to web application development. The web development ecosystem was so inferior to the desktop that we are still trying to catch up with the state of the art 20 years ago. One of the earliest victims of the move to web was performance. In desktop apps the expectation was immediate (maximum of a hundred milliseconds) response times. When the world wide web arrived we were suddenly facing 10-20 second response times. Dark days for user experience.

Since the late 90s the web has slowly improved. We are now able to experience near-desktop performance with our web apps. Most of this is due to dramatically improved bandwidth. Another contribution was the move to ajax, web services and single page apps. Rather than making page requests for each transition we are now making very small, efficient data requests. 

In spite of these improvements I still find teams setting very low expectations for performance (example: "3 second" service level agreements for service requests) which makes me believe that teams do not understand WHY performance is important. This is understandable given where we have been the last 20 years. Crawling back from 20 second response times does not make one impressed at the distinction of 2 seconds vs. 200 milliseconds. In days past people evaluating performance would consider the wasted time of the user "waiting" for the app. If the average response time of the app was 3 seconds then 3 seconds of the user's time was wasted for each request. If the user made 100 requests per day they were wasting 300 seconds (5 minutes per day). Not that bad. Although we have improved our measurements systems through the decades, the assessment of the "impact" of poor performance is often quite primitive.  We generally rely on our personal experience to qualify app performance: "it feels good". But this still does not answer the question WHY does it matter?

The answer, like most answers involving human beings, is the way people think. Human beings are very easily distracted. So easy, in fact, that our distraction time can be measured in milliseconds! This the essence of the performance "why". If it the app takes too long to respond our active little brains move on to something else. And, unfortunately, it takes us a while to return to the subject at hand. So... the effect of waiting for 3 seconds could mean that the user actually wastes considerable time...and take longer to handle the next question. An IBM study in 1982 showed that programmer productivity dramatically improved (almost 2x) when response time dropped from 1.5 seconds to 400 milliseconds. The improvement is not linear: improving from 700ms to 400ms makes a huge difference. Studies since have found similar effects for other user communities.


So...the next time somebody asks why you are insisting that response times must be less than half-second you can tell them "because my attention span isn't very good"

Comments

Popular posts from this blog

Managing Risk and the Shadow Backlog

As an approach to developing software agile has had a profound impact.  There are many great architectures, languages, libraries, frameworks, etc. that have helped software engineering get better. But in my experience almost none of these has been as important as the process of agile. There are many advantages to agile but one of the most important but least articulated (especially to executive leadership...who should care the most) is risk management.  Unfortunately, this aspect of agile can also be misunderstood by the practitioners: the development and test team. So why does agile reduce risk?  Because the agile process creates transparency.  Nothing creates more risk than hiding information.  Nobody can make a decision to reduce/avoid risk if they are not operating with good information.  This is not to suggest that teams who are developing using waterfall approaches are intentionally hiding the truth of their project's progress.  Rather, the p...

We need a new front-end language

I like to preach to software engineers that       the essence of software engineering is    designing for complexity . I also preach that       coding = design . So transitively speaking       coding = designing for complexity . I deeply believe this (and you are going to hear it often in this blog).  While there are many important skills a coder brings to the job designing for complexity (DC henceforth) is our bread and butter. Yes, there are other important talents we bring to coding... Performant algorithms, Cool animations Understanding new and adjacent new technologies etc. These are important and often are the most fun part of the programming job but we spend most of our time (80%+) on DC.  A good programmer is thinking about design when writing every line of code.  "How will it relate to the other code in this app?", "how will it stand-up to change?", "will the next developer (or even me 6 month...