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