I’m starting a new series on this blog today called “Calling for Backup.”
We’ve all had those conversations, where we’re arguing something that really should be a no-brainer and, yet, the person we’re arguing with is…well…arguing. I find these situations difficult because trying to explain my reasoning is kind of like explaining why I breathe.
ThickHead: “Why do you keep breathing, it looks like so much work!”
Me: “Because if I stop I’ll die.”
ThickHead: “Nahh, I’ve never heard of anyone dying because they decided to stop breathing. Prove it!”
I’ve finally learned that a very effective tool in these situations is a story. The more real, the better. But my biggest problem is that I don’t walk around cataloging stories so I can just whip them out on demand. I doubt you do, either.
So, my series, “Calling for Backup” will be an attempt to catalog stories in a format that makes them easy to reference. So next time, I hope your conversation will be more like this:
ThickHead: “Why do you want me to attach a profiler to our system to find its performance bottlenecks? We haven’t used one in ten years and we’re fine. Besides, I’m absolutely convinced if we move from Weblogic to JBoss everything will be ten times faster.”
You: “If you haven’t attached a profiler in ten years I will bet you money you’ll find juicy, easy to fix problems.”
ThickHead: “Nah, it’s too much work. Jonny tried it once in 2003 and our app server fell over because it was too slow. Plus it will take at least, what, a full day of a developer’s time? Thanks anyway.”
You: “Here’s the thing. Tim Cull found two different problems on two different real systems that manage billions of dollars using a profiler. And they were easy to fix and there’s no way anyone would have found them without a profiler.”
ThickHead: “Oh, I see what you’re saying. Well, ok, you can have a day or so.”
Stay tuned. The first Call for Backup will be about exactly that: why you should use a profiler.
