LinkedIn

See our LinkedIn profile, click on this button:

APDEX

How Fast is Fast Enough?

Modern life is about speed-rushing to keep up. Your business application had better run fast, faster, fastest. Conventional wisdom dictates that application response time must always be faster. Whatever speed your users experience today, it had better be half that next year. Stop! Think about the consequences.

I once met with a client with a serious business problem-an application used by partners to support the company was too slow. So slow in fact, that frustrated partners were defecting to competitors. Everyone agreed that the response time was too slow. But when I asked, “How fast should it go?” chaos ensued with 20 people arguing over the target time. 

In the end they agreed that it should go faster as soon as possible and keep getting faster indefinitely. Peter replied, “This is good news since you just hired our firm for an indefinite contract that will have an infinite price!” The room went quiet, then people asked how they should determine how fast is fast enough.

There is no shortage of experts on this topic. James Gleick wrote a fascinating book entitled “Faster: The acceleration of just about everything.” His book is replete with examples of how the world has sped up as technology has enabled faster transportation, production, and communication. His thesis is that processes will go faster until we live a uniformly nanosecond world. When he wrote the book in 1999 he thought that day was nigh. But note that one of the great speed icons of that day-the Concord-was retired soon thereafter in 2003. There are no supersonic commercial flights available today. How can that be? Faster hit a limit.

No doubt some things will continue to happen faster, especially if is the speedup has a direct tangible benefit. The tangible benefit to business is improved productivity (more for the same money) or higher revenue (more money for the same effort). Did you notice the word money appeared twice? The first business rule of speedup is that it must improve the bottom line. The second rule is that the money it contributes (income or savings) must be greater than the cost.

Many projects that improve application response times are not cost effective. All technology improvements reach a point of diminishing returns, and business application speed is no exception.

I have had many animated conversations with colleague Peter Christy at the Internet Research Group over the years about the push and pull between “it’s never fast enough” and “speed has practical human-computer interface limits.”  The last time they had this conversation Peter Christy cited research that the human nervous system transmits cell-to-cell signals at about 1 millisecond. [Note that the brain and nervous system do that many times in parallel so the bandwidth must be big.] Peter Christy postulated that we won’t reach the limit of application response time speed until the computer interface matches human capabilities.

Many speed targets have come and gone over time. There was “the Web must respond in 8 seconds” rule promulgated by Zona Research at the turn of the millenium. Jupiter Research recently replaced that with 4 seconds as the new threshold of acceptability for retail web page response times.  And there is the old IBM 1 second rule from the 1970s. All of these rules were proposed by organizations with a vested interest in speed. By the way, they all told us that the world as we knew it would end if these speed rules were not achieved immediately. Has Microsoft gone bust because nothing on Windows happens in less than a second, or is Amazon just a mirage since most of their web pages load in more than 4 seconds?

The upshot is that if you believe that faster is always better, you are likely to spend too much, and however alluring one inflexible “fast enough” speed may be, it is a bad idea. The “right” speed depends on context. That context is a complex fusion of what the user needs to accomplish and how the application is designed. Taking this context into account is key to the Apdex methodology. Enterprises must figure out how fast is fast enough for application users to have a satisfactory experience.

I will be explaining Apdex approaches to determining the proper target time “T” in future posts.

But for now I have run out of time.

1 comment to How Fast is Fast Enough?

  • Peter,

    Your post touches on a number of related topics. Last year, in a post about Acceptable Response Times, I linked to several other posts and articles that discuss these topics in more detail.

    To summarize my analysis, I conclude that the “right” speed for any online interaction is a function of five variables:

    Context (the type of operation or function being performed)
    Complexity (simple tasks should be done faster)
    Customer experience (how the user will perceive the interaction)
    Competition (how competitive sites/tools/products behave)
    Cost: a faster implementation must also be cost-effective.

    Complicating matters, these three variables are themselves inter-related. But I think they can provide a useful framework for anyone who sets out to answer the question: How fast is fast enough? And they certainly do help people to get past the mistaken notion of a single “rule” about response times.

    –Chris

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  


*