Why I don’t blog about “great code”

Last week I heard a Stanford researcher describe how failure can be a good thing, if we are prepared to learn from it.

I agree, although this mindset is easier to describe than to achieve. So here I’m kicking off a new series of posts about mistakes I’ve made over the years, and what I’ve learned from them. Look in the “Mistakes” category for more like this.

If you’ve followed my blog at all, you’ll know that I regularly return to the theme of what constitutes good code. Ever wonder why I don’t get more ambitious and talk about “great code” instead?

A big reason is that in software, great can be the enemy of good.

If you’re a fan of aphorisms, you’ve probably heard the opposite statement a few times: “good is the enemy of great.” People who say this are emphasizing the value of setting lofty goals, and then aligning our day-to-day lives to deeply held priorities. They remind us that settling for mediocrity is almost guaranteed not to create deep meaning or purpose. And they are quite right.

However, I submit that the greatness you should be pursuing in software is less about producing great code, and more about becoming a great producer of code. And great producers of code know that most of their creations will not optimize business value if they aim for a magnum opus. Not every commission can be the Sistine Chapel.

Detail from the Sistine Chapel, by Michaelangelo. Image credit: Wikimedia Commons.

Don’t get me wrong. I care about the quality and artistry of code, and there is definitely great code out there. It’s just that I’ve got these battle scars…

Daniel builds a tower

In 2001, I helped design and code 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.