Turn Left at the Last Traffic Light

It happened a while ago – before GPS devices, and before Google Maps or Mapquest. I was trying to drive to an address in a small town and I did what reasonable people did back then: I asked someone at a gas station for directions. One detail from the directions stands out in my memory: the gas station attendant told me to “turn left at the last traffic light.” I was so astonished that it took me a few seconds just to react. Then I asked him, “How do I know which traffic light is the last one?”

Maybe you’ve never gotten directions like that, but I’ll bet you’ve seen or heard similar statements. Here are a few of my favorites:

Crazy Statements

– Buy at the bottom.

Of course we’ll only know we were at the bottom after the market has climbed for a while, but the advice sounds good.

– Cook it until it’s done.

This is actually meaningful to some people, but not to someone who doesn’t know how to recognize the appearance of food that is fully cooked. I fall into the latter category.

– Keep testing until you find the last bug.

I guess in theory there is a “last bug,” but I’ve never found it. There always seems to be one more hiding out there somewhere.

– Just make the new system do the same things the old one did.

It’s not obvious when you first hear it, but this kind of requirement includes three parts:

1. The documented things that the old system does

2. The things the old system does that aren’t in the documentation (some of them probably just work that way by accident – they weren’t designed that way at all)

3. The things the old system doesn’t do that are in the documentation

Good luck finding them all. And you’ll need even more luck to have the new system recreate them.



– Give me a disaster recovery plan that anticipates every possible disaster.

I guess that should include the possibility that I go crazy and destroy all of the backup hardware.

– The IT Strategy should align with the business strategy (but I won’t tell you the business strategy).

A passive-aggressive classic. The “Catch-22” of IT.

What do all of these statements have in common?

They all sound meaningful at first glance, but they provide advice that is useless to the listener without additional information – information which isn’t being provided, or which maybe doesn’t even exist.

What should you do when you’re given one of these crazy statements?

Ah, that’s the important question! I’ll answer that for each of the statements I’ve included so far.



How to Answer Crazy Statements

– Turn left at the last traffic light.

Ask how you’ll recognize the “last” traffic light. Is there a street name? A landmark? Does it have a sign that says, “last traffic light”?

– Buy at the bottom.

This one’s a matter of risk. Statistically, you can assume that there’s been a short-term bottom when the index or stock you’re following gains a certain amount. The more the stock gains, and the longer it stays above the bottom, the more likely it is that a worthwhile bottom was reached, and that it’s time to buy. It all comes down to how much of a premium you want to pay for risk minimization. Wait a day or a week and the stock may go below its last bottom. Wait a year and the bottom is more assured, but you’ll have to pay a higher price for the stock.

– Cook it until it’s done.

Ask for hints: About how long will that take? What should I look for? Bubbles around the edge? Browning? Smoke coming out of the oven?

– Keep testing until you find the last bug.

I’ve heard people suggest that you base this on time: that you test until you haven’t found a bug within a certain amount of time. But time isn’t a good predictor if you’re just running the same tests over and over. I once heard a better solution (I think it came from Jerry Weinberg) that suggests that you take a piece of software that is being tested and you artificially create a certain number of bugs in the software – in effect you “seed” the software with bugs. Then you see how many of the seeded bugs are discovered during testing, and how long it takes. This should give you some idea of how many real bugs still lurk out there waiting to be discovered. In most cases – assuming the people who plant your seed bugs try to make them subtle – you’ll probably find it difficult to find all of the seeded bugs. (Remember to take the seeded bugs out of the software – and then retest – before you release the software.)

– Just make the new system do the same things the old one did.

The best way to deal with this requirement is to refuse to accept it. It is virtually impossible to exactly duplicate the way a piece of software works without developing it using all of the same tools. Since in most cases you’re replacing the software because it uses obsolete tools or technologies, you need to go back to square one when redefining the requirements. Work with the system users to extract the essence of what the old software does. Focus on the process the users go through in using the old software, and try to find ways to improve the process. Then develop new software that optimizes the performance of the users with the new improved process. If the user process is improved, then no one will care whether the new software works exactly the same way as the old software.



– Give me a disaster recovery plan that anticipates every possible disaster.

Disaster recovery is a risk/reward game. It’s OK to brainstorm a set of crazy risks; in fact, it’s a good idea to try to list anything that might possibly go wrong (I say “try” because you’ll never anticipate everything). Then try to categorize all of the risks on your list into scenarios where the disaster recovery can be done the same way. You’ll eventually arrive at a short list of scenarios that you need to plan for. Evaluate the cost of providing for each scenario and compare it to the probability and cost of not having any disaster recovery plan available. Then work with the business to make decisions about how much to spend on preparing for each scenario.

– The IT Strategy should align with the business strategy (but I won’t tell you the business strategy).

This happens more often than you’d think. I tell IT executives that when they can’t get business executives to tell them the business strategy (or when the IT executives can’t be involved in the creation of the business strategy in the first place), then the IT executives should write down what they think the business strategy is, and what the corresponding IT strategy should be. Then they should go back to the business executives and give them this speech:

“I haven’t been able to get a clear idea of what our company’s business strategy is, so I’ve put together my own assumptions. Here they are (show them the key points of your version of the business strategy), and here’s what I think IT should do to support this business strategy.”

What you’ll find is that most business executives who are hesitant to reveal what they consider “privileged” information are much more likely to correct your own assumptions. So through their corrections you’ll end up getting the business strategy information you need.

Conclusion

If you’ve been watching any of the political debates lately, you know that although most debates start with a question, a good politician knows how to use the question as a springboard to answer another question that better suits his or her agenda. When you’re confronted with one of these crazy statements, treat it the same way. Use it as a starting point, and then ask clarifying questions to get at what the speaker really means. This is an obvious approach for many people, and yet it’s not obvious to most IT people (see my July, 2006 newsletter article “5 Reasons Why IT People Love Lists” for a little bit about why IT people think that every question needs to be answered). When confronted with a crazy statement, you need to “uncrazy” it before it can become useful.