My favorite engagement is when I’m brought in to help a good person who’s overwhelmed. The manager knows his DBA is smart, but the DBA is just flat out overworked. Too many developers are slinging too much code on too many servers, and there’s too many signs of smoke. The manager asks the DBA who he would pick if he could pick any SQL Server guy in the world to help out, and my email goes to Inbox Plus One.
In situations like this, I have to jump aboard a moving train. My biggest value is that I can tell the DBA, “Don’t worry, I’ll take the arrows at this next meeting. You stay back in the cube and keep working.” I have to respond to questions without knowing the slightest thing about the amount of work involved. I can’t ask for precise measurements of past performance – I have to shoot from the hip, and I have to do it fast.
The Situation: The Angry User
Ripley: “We’re having problems with the Hyperdine 120-A2’s. The hand motion is pretty quick, but we need them to go faster.”
Me: “How much faster?”
Ripley: “Well, I’m not sure. I’m not sure how to measure how fast their hands move. We started this test with a knife. Put your hand on the table and I’ll bring one in to show you.”
Me: “No thanks, that’s okay. Let’s keep it simple – do you want it to be 10% faster, 100% faster, or 1,000% faster?”
What That Line Does
I purposely use the 100% and 1,000% numbers instead of the easier-to-understand “twice as fast or ten times as fast” metrics because I want them to stop and think through the metrics. I want them to think about what those percentages mean, and more importantly, think about the vast differences in those numbers.
Those numbers don’t just refer to speed improvements.
They hint at work requirements, too.
See, the more they think about what it means to get something to be 100% faster or 1,000% faster, the more they’ll understand the fundamental differences between performance tuning and rearchitecting. They’ll realize that they’re not just calling me in to tweak a few little knobs – if they need something to go ten times as fast, I might make a very big suggestion on how they’re using technology. Admitting that you need something to be 1,000% faster means you’re willing to make some radical changes.
Sometimes, a judicious use of just the right index, query tweak, or configuration can improve performance by 1,000%. When I’m doing a very first round of performance tuning for a new client, that word “sometimes” might even be replaced with the word “often.” But before I go saying a simple new index will solve everything, I want the client to tell me how high I need to aim.
What Happens Next
I consider this line a success if the other person blinks and thinks, and they almost always do.
Ripley: “Uh…well…I guess it needs to be ten times faster.”
Me (nodding and making a note): “I see. That’s a pretty big jump. Okay, what else?”
Ripley: “You can do that?”
Me (with a grin): “I can do just about anything – that’s why they brought me in. I have no baggage, no politics, and no excuses. I’m just a hired gun.”
Ripley: “Ah, so the more work I want done, the more money you make!”
Me: “Exactly. So go ahead – let’s go through everything you’re frustrated with, and how much of a difference you need.”
By simply acknowledging the size of the jump and moving on, I’m setting up a silent contract between me and the user. They realize that performance costs money, and they start taking politics out of their decisions too. They build a mental shopping list and associate it with dollar signs, and you’d be surprised at how that tempers their demands for more performance.