Why Exceptions Aren’t Enough

(This post is a logical sequel to my earlier musings about having a coherent strategy to handle problems.)

Back in the dark ages, programmers wrote functions that returned numeric errors:

if (prepare() == SUCCESS) {

This methodology has the virtue of being simple and fast. We could switch based on the error code. A “feature” of our apps was that our users could google an error code to see if they had company:

Image credit: xkcd.com

However, as we wrote code, we sometimes forgot to check errors, or tell users about them:


Admit it; you’ve written code like this. So have I. The mechanism lets a caller be irresponsible and ignore the signal the called function sends. Not good. Even if you are being responsible, the set of possible return values is nearly unbounded, and you get subtle downstream bugs if a called function adds a new return value when a caller is switching return values.

Another problem with this approach to errors Continue reading

Steve Tolman: It depends.

(A post in my “Role Models” series…)

My friend and long-time colleague Steve Tolman has a standing joke with people who know him well. He gives the same answer to every question: “It depends.”

Unlike most jokes, this one gets funnier the more often you hear it, especially if Steve gives a cheesy wink during delivery.

Nope, not Steve. Photo credit: Wikimedia Commons.

Dead serious, high stakes discussion. Breathless delivery: Should we build feature A or B?

“It depends.” Wink, wink.

How fast can we do a release?

“It depends.”

Do you want ketchup on your hamburger?

“It depends.”

Maybe you have to be there.  ;-)

Steve doesn’t use his favorite answer because he’s lazy; he’s one of the hardest-working, hardest-thinking guys I know. He uses it because important questions often have rich answers, and unless all parties share an understanding about the priorities and assumptions underlying a question, sound bite responses aren’t very helpful. The answer is supposed to remind everyone that a thoughtful approach to business priorities, not slavish conformance to a rule book, is what will drive economic success. Steve generally follows his answer up with a series of probing questions to help everyone rediscover that truth, and to get our creative juices flowing. “It depends” is an invitation to deep discussion, which often produces insight we sorely need.

I see a strong connection between Steve’s tongue-in-cheek answer and the sort of tradeoff analysis that informs smart engineers’ thinking. As I said elsewhere, good code is balanced. You take many competing considerations and find the approach that best addresses business priorities (note the plural on that last word). You don’t get dogmatic, because you know that no extreme position is likely to optimize competing considerations. But you don’t get so pragmatic that you give up on vision and passion, either.

Steve gets this.

You might feel that “it depends” thinking is incompatible with the “put a stake in the ground” principle I blogged about recently. “It depends” invites further discussion, whereas stakes end debates. Right?

I don’t think so. You just use these strategies under different circumstances. “It depends” makes sense when shared understanding hasn’t yet developed. Stakes make sense when you all know the context and are still unsure how to proceed.

So what’s the right ratio of winks to stakes?

It depends. ;-)

Thanks for the lesson, Steve.

Action Item

Next time someone asks you for an overly simple answer, tell them “it depends,” and then let them make the next move. Betcha they’ll ask for detail and listen to your explanation more thoughtfully.