THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

The Right Question

Introduction

This post is the tenth part of a ramble-rant about the software business. The current posts in this series are:

This post is about the importance of identifying or recognizing the right question, and continues the discussion started in Metaproblems: Drama.

When You Find a Problem, Throw a Party

Why? In software, finding problems is the hard part. Fixing problems is easy.

Cutting through the symptoms and excavating effects until you reach a root cause is a lot of work. There are a million subtleties to examine and rule out. And to make matters worse, problems of similar complexity can take vastly different amounts of time and resources to locate. Why? Excellent question. My answer: I don't know.

The best I can do at this time is warn you of the observed trend. I often use an analogy to communicate this. "It's like looking for your car keys" I say. "They're always in the last place you look." Some astute individuals point out that when you find your car keys you stop looking, to which I reply: "Exactly."

Someone recently asked me how long it would take to fix a software issue. My response was "Fifteen minutes." "Fifteen minutes? Wow!" was their reply. "It might take me a week to find it, but I'll be able to fix it in fifteen minutes." Software is like that... welcome to my world.

The Right Question

Often, identifying the Problem is immediately preceded by asking the right question. Why does this help? Framing the question forces your mind to order the facts. You have to consider what you know and what you don't know to ask a good question. In fact, the right question will take into account all you know and ask about all you do not know.

"Really Andy?" Yep, really. The right question may not be exhaustive - it could be about the next step in a series of unknown steps. Does the right question have to include all the other unknown steps? Nope, if you know there are a host of unknown steps, the right question implies moving closer to the other steps in the solution by identifying the nature of the next step.

A Proper Response

The Right Question is also the proper response to a Problem. Rather than an emotional rant (like the one described in Metaproblems: Drama) when a hard drive failure takes down a production server, the Right Question can move you towards the immediate solution, more preparedness, higher availability, and less downtime. If you can minimize the drama - or circumvent it entirely - your team can concentrate on process improvement. This can start a positive cycle where one good inspires / fuels another, and that another, and so on.

Process Improvement

I remember my first stint as a manager. I met with the team and asked "What do we do?" Most of the responses were along the lines of "All day long I put out fires." I then asked "What do we want to do?" Again, most of responses shared a theme: "Be proactive, not reactive."

One important note here - the team already knew what they wanted and needed to do. They didn't need a manager telling them...

Process improvement is all about going from reactive to proactive. The first team I managed pulled this off by asking the Right Question, which was "How do we get from reactive to proactive?" We identified a metric - DBA-hours - and started tracking our activity. Applying some analysis, we found 90% of our time was spent reacting and 10% was spent on developing long-term solutions. An example of reacting is: Making changes to data. An example of developing a long-term solution is: Altering a stored procedure to properly insert the data in the first place.

We identified a crucial middle-step. We called it "fighting fires better." To facilitate this, we documented procedures for common, recurring fixes. We created a script library that started with hard-coded scripts and grew into parameterized scripts. This work later served as the basis for most of the solution development.

Conclusion

The Right Question is the proper response to a Problem. Metaproblems - especially drama - are not.

:{> Andy

Published Friday, February 12, 2010 8:00 AM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Jack Corbett said:

Good advice, but what do you do when your problem is finding the right question?

February 12, 2010 7:55 AM
 

JonMCrawford said:

Well said, Andy.  IMHO, finding the right question is ALWAYS the problem. I think it goes back to the Metaproblems:Drama chapter, cut away the 'story' and get to the problem itself. Then, from above: "You have to consider what you know and what you don't know to ask a good question. In fact, the right question will take into account all you know and ask about all you do not know."

As with anything else, having a method to attack problems with (even discovery of problems) makes things easier.

February 12, 2010 8:33 AM
 

SQLRockstar said:

Andy,

your posts lately have been wonderful. so good, in fact, that i am including you in my 'model' list of bloggers.

http://thomaslarock.com/rankings/

you can find your badge at http://thomaslarock.com/2009/05/updated-rankings-3/

keep up the great work and i look forward to the next time we can chat for an hour in some remote airport.

February 12, 2010 9:35 AM
 

Chuck said:

Great stuff as always, Andy.

When I was in grad school in 1995, a Prof shared how she was building a DSS to assist an ER Team and when interviewing the ER Docs she learned that the key in saving life was correctly navigating the "decision tree". Asking good questions is EXTREMELY important.

Chuck

February 12, 2010 11:51 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement