Month: May 2013

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 →

Good fences make good neighbors

In Robert Frost’s poem, “Mending Wall”, two farmers meet each spring to rebuild the rock wall between their properties. One farmer is the narrator. He notes that the unseen forces of winter and weather always cause some decay (“something there is that doesn’t love a wall”), and he wonders why the wall is necessary. There’s apple orchard on one side, and pine forest on the other–it’s not as if something will be kept in or out. The other farmer answers with the repeated aphorism “good fences make good neighbors.”

photo credit: DragonWoman (Flickr)

This poem could be a treatise for the principle of encapsulation in software. In software as in life:

  • Something there is that doesn’t love a wall.
  • Good fences make good neighbors.

What doesn’t love a wall?

Subroutines, formal interfaces, data hiding, class hierarchies, the pimpl idiom, and similar mechanisms all create barriers in software between consumers and providers of functionality. These techniques are well known, but we still have codebases littered with protected data members, unnecessary class declarations in headers, goto, and other suboptimal choices.

Why? Continue reading →

Why Your Software Should Cry

The problem of pain has bothered philosophers–particularly those with a religious bent–for a long time. What might be the purpose of suffering, they’ve wondered, and how does it relate to the human experience?

But pain barely impinges on the thinking of software engineers at all. Computers never wince, or complain, or mourn the loss of a favorite program (Marvin the paranoid android excepted). An OS runs at full speed until the instant when its kernel “panics” without warning; once you reboot, it acts as if nothing ever happened. No sniffles, no whimpers, no scabs…

photo credit: nanny snowflake (Flickr)

This is unfortunate.

Reaction to stimuli is one of the 8 characteristics of life. That means that living things are aware, in some sense, of their relationship to the larger environment. They distinguish between good and bad stimuli. They hurt. And they learn from their pain.

Lessons from a protist

This ability to use pain is not limited to complex organisms. The lowly Stentor roeselii (a single-celled protozoan that anchors for filter feeding) exhibits an incredible repertoire of behaviors to optimize its relationship with the environment. Squirt it with water from a pipette, and it contracts for defense. 30 seconds later, it unfurls again. Keep squirting, and it eventually learns to ignore the false alarms.

Gently introduce a poison into the water current, Continue reading →