Technology – Page 198 – IS Survivor Publishing

How to measure response time (first appeared in InfoWorld)

Back when I studied electric fish I learned a valuable lesson from my research advisor: not all criticism in my professional life would be phrased with concern for my ego’s ongoing desire to inflate. The following episode, which also provided a second invaluable insight, led me to this conclusion.

My research involved a quantitative analysis of behavior. After some nasty FORTRAN programming and some manual charting and graphing, I showed it to my advisor.

“What’s it mean?” he asked. My answer involved the mathematics of information theory, capped by a precise measure of the communication between two interacting fish. Nobel Prize material.

“But what’s it mean?” he asked again, impatiently. When he failed to hear a satisfactory answer he told me to stop bothering him until I could explain it in English. I knew the number, but not what it meant.

Just for giggles, let’s take the same potshot at a basic number used in the specs for information systems: response time.

Oh, the concept is fine. Unfortunately, we usually measure it in units of time, which demonstrates our lack of insight into its meaning.

“The benchmark transaction completed in .782 seconds,” we might say. Or, in comparing brands and models of personal computer, “Model A completed our benchmark task in 1 minute 34 seconds, clearly outperforming Model B which completed it in 1 minute 51 seconds.”

Precise, measures, yes, but they mean very little.

The reason? Look from a customer-value perspective, remembering that “Customers define value,” is the first of the three rules of management. Response time isn’t a continuous numeric quantity. Customer-valued response time (for most of us) has only six values, and none of them is a number. Those values are Eye-blink, Quick, Pause, Delay, Break, and Overnight. To elaborate:

An eye-blink is, from a customer perspective, instantaneous. Never mind that sufficiently sensitive instruments can measure it. It takes place faster than a person’s ability to notice. Eye-blink response time is perfect. You can’t improve on it.

Quick processes happen fast enough that users don’t pay attention to them. The wait is noticeable, but not obtrusive. When we talk about “sub-second response time” we’re really saying we need it to be quick.

A pause breaks our rhythm, but doesn’t let us do anything else useful. Lots of computer processes cause us to pause. Printing a one-page memo results in a pause. So can saving a long document to disk or downloading a small, well-constructed Web page from an adequately powered server via modem. Likewise database updates when response time is bad. Pauses are awfully annoying. Every pause requires the exercise of patience, and each of us has only a fixed amount of patience available for our use each day.

Delays take longer than pauses – enough longer to do something useful. We can take a gulp of coffee during a delay. Sharpen a pencil. Dial a telephone number. File a document. In many respects a delay, while longer than a pause, tries our patience less. Loading nearly any application in Windows causes a delay. So do most Web pages.

Breaks are even better than delays. You can refill your coffee mug during a break. Ask your boss a quick question. File several documents. Booting your computer gives you a break. So does faxing a document through your fax/modem, or running a report off a medium-sized database.

Anything longer than a break may as well wait until you leave for the night. Start it up, go home, see the result the next morning. If you want to be daring, start it up before you leave for a meeting instead.

That’s it. Six possible response times. You haven’t improved response time until you cross a boundary from one to the other.

And that’s not always an improvement, because sometimes, you just need a break.

Why IS is like golf (first appeared in InfoWorld)

If it didn’t happen this way, it should have: On the great golfer Ben Hogan’s 70th birthday, I’m told, an interviewer asked if he had plans to retire. “Retire?” Hogan is supposed to have responded. “People retire to fish and play golf. I fish and play golf now!”

Management consultants have an unfortunate penchant for sports metaphors. So, it occurred to me the other day as I searched for my ball that IS management and golf have a lot in common. To those of you who play the game I need go no further. For the rest, I’ll explain some of the parallels:

1. When your golf swing goes off, you try solutions more or less at random to fix it. When a computer program that used to work crashes, programmers often do the same.

2. Sometimes, the tools we use in computing just don’t work the way they’re supposed to. The same can be said of golf clubs.

3. In golf, even when you can reach the green in one shot it usually takes two putts to get the ball in the hole. With computers, even when you have a relatively easy problem to solve you usually need two iterations after delivering the product before you satisfy the user.

4. With computers, no matter what new snazzy tool you buy someone announces a better one right after you spend your money. That’s true of golf clubs too.

5. In golf there’s par, but most of us are pretty happy getting a bogey. With computers there’s the project plan, but we often feel pretty good if we only need one extension to finish the project. (By the way, for those of you on Year 2000 projects – you won’t get an extension. Sorry.)

6. In IS we often work in politically charged environments. Keeping your head down can be important. In golf you want to keep your head down, too.

7. Many greenskeepers resent those pesky golfers who mess up their beautiful golf courses. Many network managers resent those pesky end-users who clog up their pretty networks with unwanted packets.

8. On a related note, too many users on the network slows down response time. Too many golfers on the course slows down play.

9. Golfers remember the sport as being fun, but when we’re playing, at least in Minnesota, we spend half our time swatting bugs. Likewise in IS, getting rid of bugs gets in the way of the fun.

10. Most people outside of IS don’t understand why we find our profession so fascinating, and have no idea why it’s so hard. Non-golfers have no clue why golfers hit a small white ball around a field with sticks, let alone why the ball usually curves out of the fairway.

11. In golf you can hit a great-looking shot that lands nowhere near the hole. You can also hit a nasty-looking shot off the heel of your club that scoots across the grass, bounces off a squirrel, and finishes two feet from the cup. With computers, you can write elegant code that somehow fails to satisfy the users or succeed in the marketplace … and on the other side of the equation, there’s Windows.

12. Most people can become competent programmers. With time, training and hard work we can create solid programs that work well. In the next cube, though, there’s someone who speaks C++ as if it were his native language, writing code as beautiful as poetry that always works perfectly on the first compile. In golf, most of us can get the ball in the air and “out there” after a bunch of lessons and several years of practice, but we all know someone who shot par when he was twelve years old.

And, both pursuits have the same favorite phrase: “Oh %$#^!”