Courage Counts

If you’ve read Call it Courage, then you know the story of Mafatu, the boy who was afraid.

Mafatu grows up in Polynesia, surrounded by the ocean—but everything about the sea terrifies him, because he remembers his mother drowning when he was young. Determined to conquer his fear or die trying, Mafatu sets out alone in a dugout canoe, into the element that terrifies him most. He ends up stranded on an island that harbors cannibals. In one memorable scene, his faithful companion dog is endangered by a tiger shark; Mafatu jumps in the water and attacks with only a knife. When he kills the shark, he realizes that something fundamental in his heart is now different.

He still feels fear, but it no longer overpowers him.

He is free.

I’ve been blogging about the skills and mindset of effective software architects for quite a while now, but I recently realized that I’ve omitted the fundamental subject of courage.

image credit: nalsa (Flickr)

This is an important gap, because courage counts. The cleverest, most skilled architect or engineer will accomplish very little, at key junctures in a career, without it.

Symptoms of fear

In the past two decades, I’ve heard many people (myself included) make statements like the following: Continue reading

6 Strategies to Simplify Software

How do you make things simple?

I’ve written that simplicity is powerful, and that it undergirds many deep architectural breakthroughs. In posts about pragmatism and balance, I’ve quoted Oliver Wendell Holmes about the simplicity on the other side of complexity.

But I’ve never talked about how to achieve it.

photo credit: hurley gurley (Flickr)

This is not an easy question; if we knew how to make things simple, we’d do it more often and more quickly. It takes some serious effort (and genius) to go from centuries of experiments and volumes of equations to e = mc2. I’ve been pondering simplicity in software architecture for a decade, and I’m certain I’ve only scratched the surface.

Still, simplicity is a learnable skill, and some strategies are consistently helpful… Continue reading

3 reasons to prefer references over pointers (C++)

I still remember what it was like, as a C programmer, to be introduced to the newfangled concept of references in C++. I thought: “This is dumb. It’s just another way to use pointers. More syntactic sugar for no good reason…”

For a long time, I thought of pointers vs. references as a stylistic choice, and I’ve run into lots of old C pros who feel the same. (The debate on this comment stream is typical.) If you’re one of them, let me see if I can explain why I now think I was wrong, and maybe convince you to use references where it makes sense. I won’t try to enumerate every reason–just hit a few highlights.

image credit:

1. References have clearer semantics

NULL is a perfectly valid value for a pointer, but you have to do some headstands to create a reference to NULL. Because of these headstands, and because testing a reference for NULL-ness is a bit arcane, you can assume that references are not expected to be NULL. Consider this function prototype, typical of so much “C++” code written by folks with a C mindset:

void setClient(IClient * client);

With only that line, you don’t know very much. Will client’s state change during the call? Is it valid to pass NULL? In the body of the call, will client ever point to anything other than the value it had at the top of the function?

Veteran C programmers recognize that the semantics are unclear, so they come up with doc conventions to plug the gap, and they check assumptions at the top of the function:

 * @param client IN, cannot be NULL
void setClient(IClient * client) {
    if (client != NULL) { // something

This is fine, except why depend on a comment and a programmer’s inclination to read and obey, when you can enforce your intentions at compile time, and write less code, too? Continue reading

The Power of Simplicity

Most stories about zen masters, gurus, or other paragons of wisdom follow a similar pattern. The pupil discovers a problem. He or she struggles with it. The problem gets more and more overwhelming. Solutions are elusive. Finally the pupil goes to the master and pours out his heart, whereupon the master offers a pearl of insight that radically reinterprets the problem.

Seek the simple... Photo credit: departing(YYZ) (Flickr)

Seek the simple… Photo credit: departing(YYZ) (Flickr)

There’s a reason why this narrative exists in every culture: human beings need the insight that comes from synthesis, pared down to its essence. We crave the simple but profound:

  • Less is more.
  • Do unto others as you’d have others do unto you.
  • A watched pot never boils.
  • Freedom isn’t free.

The software industry desperately needs this sort of insight, but far too often I see us operate in the stage of the narrative where the pupil misunderstands the problem, struggles, and makes things worse. Continue reading

Interrupting my interruptions

Tonight I was just settling down for a ponder on some personal stuff when I noticed an email from my brilliant brother-in-law (hi, Stephen!), recommending an article about the cost of interrupting programmers. Half an hour later, I’m blogging about it. Yes, I see the irony in the read, the blog, and the shout-out, but I just can’t help it.

I’ve heard lots of estimates of the cost of interrupting, but the research in this article seems particularly clear. I think the article oversimplifies by assuming that the problem and solution derive purely from memory, but there’s enough insight and clever thinking in the article to make it worth a read…

We’ve all known that interruption = bad. We’ve nodded our heads at this wisdom for years. Occasionally we give lip service to it. We try to clump meetings in one portion of the day, leaving blocks of time for serious thinking and work. We advise our teams to use “lighter” interruptions (“ask your question by chat/email instead of in person; it’s less disruptive…”). We decline non-essential meetings and urge others to keep their invite lists small. We buy “cones of silence” and “Do Not Disturb” signs and set them up outside the cube of the guy who’s trying to finish urgent work for an impending release.

And then we fall off the bandwagon.

At least, I do.

Hi. My name is Daniel, and I’m addicted to interruptions. :-)


Image Credit: xkcd


You would see my addiction if you walked past my desk and looked at the tabs in my browser: two for email (work, personal), two or three for calendaring, some chat sessions, a task list, several programming topics, a man page, a python reference, an interesting blog post or two, three wikipedia pages, a ticket I looked up before I ran to my last meeting, a wiki page I’m in the middle of editing, a competitor’s product portfolio, a LinkedIn discussion forum on cloud computing, a Google spreadsheet, the PDF of a resume I’m supposed have read before I do an interview in an hour, half a dozen random sites that I visit during the day as I check gossip on a competitor or read the Dilbert cartoon someone emailed me…

How am I supposed to think Deep Thoughts when I’ve got that much noise?

Continue reading