Monday, July 6, 2009

AGAIN!?

Sometimes you have a problem (not good). And sometimes that problem goes on for a while (even more not good). When that happens, it's easy to get frustrated. For everybody.

"You want MORE logs?!"
"Okay, you really want me to reproduce this AGAIN?!"
"Reopened!? Again!?! No change?! Yikes!"

It all comes down to a collective cry of "Aren't we getting ANYWHERE?!".

Yeah, that point. We've all been there.

Here's the thing. Frustration is just like any escalating behavior. It's perfectly legitimate to be frustrated. Generally, you're not the only one who is feeling that way. And it's inevitable that it will come out. You'll start to see the signs: extremely precise parsing of sentences; the formation of we and they (with "we" being the injured party); intimations that "I'm not going to do anything until someone else does some darn work around here!". None of this is fun, but it's all pretty normal.

The negative of the spiral here is that someone else's frustration will only increase yours, and venting your frustration will only increase theirs. You have to stop the spiral.

So how do we do this?
  • Do not let their frustration make yours worse. Take a deep breath before you reply to anything.
  • Acknowledge the frustration, out loud and ask for the venting to stop. Note that you're frustrated, too and that you're all working together to try to help. Venting isn't going to help anyone.
  • Explain why. If you're asking for work (more logs, a new debug build, reproducing this again), describe what you're hoping to get out of it. It gives the action purpose instead of simply making it look like you don't have a clue.
  • Solve it. Ultimately, frustration levels will decrease when the problem goes away.
Frustration is part of daily life. Systems are complex enough and generally finicky enough that there will be hard problems, and problems that take a while to solve, and that's frustrating. How you handle that frustration - yours and someone else's - will help determine how quickly and well you get to a solution.
Posted by at 12:57 PM

2 comments:

  1. I've also run into this cycle a few times (no coincidence, since we work at the same place!). Here's something I do to stop unproductive circling in it's tracks (it's sort of an extension of "Explain why"):

    1. Generate several experimental hypotheses up front, and rule out the ones that are already contradicted by the limited data you already have. Keep thinking things through until you you have a few mutually exclusive hypotheses that you can neither confirm nor reject with the current data. Hopefully some of them are actually plausible; it would help to know which are more plausible than others.

    2. Figure out what observations you'd need to make in order to distinguish one hypothesis from the other. Will "reproducing" the issue and getting more logs give you the observational data you need, or are you just stalling? If another experiment won't give you the data you need, why bother running it? Maybe you need to find other, possibly indirect and imprecise measurements that are only roughly correlated with what you're trying to measure (e.g., I can't measure how fast the system is, but I can tell how often the user takes a coffee break).

    3. Design the experiment and make sure you're prepared to make the observations you need.

    4. Given what you *think* you know about the system, make predictions about what *should* happen. In other words, surface your assumptions early on. That way, when you look at the data later and notice one funny datapoint ("eh? where did that extra latency between requests 55923 and 55924 come from?"), it will catch your attention and let you either generate more hypotheses or design a more controlled experiment.

    5. Carefully control your variables and run the experiment.

    6. Look at the data -- have you figured out the issue yet?

    7. Iterate. Even if you didn't nail the issue on the first try, the progress you're making will be obvious and will help to limit frustration.

    The Scientific Method -- ain't it great? More often than not, you'll get to the root of the problem in only one or two iterations.
    ReplyDelete
  2. Very true. I know I've been guilty of the "I don't know what to do. Let's reproduce it again" trap. If we can't say what's changed, well, we haven't really defined our hypothesis and our experiment well enough.

    The only point I would dispute is the one about variable control. While it's a laudable goal, depending on how much the system that you're working with is under your control, you may get close (or not so close) to that level of control. Sometimes you simply have to deal with several variables changing at once, even though we'd like to be able to change just one.
    ReplyDelete

Subscribe to: Post Comments (Atom)