backup

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 →

Why Cannibalism May Be Smart Business

Get out your fork. I’ve got a story for you…

Dig in. Don’t hold back. Photo credit: AleBonvini (Flickr)

At the beginning of 2005, Symantec acquired Veritas. Together, Veritas’s BackupExec and NetBackup products accounted for something like 70-80% of the world’s enterprise backup market. As I recall, BackupExec had annual sales of around $600M, and NetBackup was similar.

I worked for the only technology group within Symantec that overlapped the backup space at the time. We were making a disk-based backup product named LiveState Recovery; its revenues were in the tens of millions of dollars and we were growing at >100% CAGR.

Integration gets hairy

Our growth stemmed from the fact that we were approaching backup in a radically different way. Instead of capturing changed files and streaming them through a centralized media server to a tape library, we took disk images based on snapshotting technology. We were faster (many times faster, often); we had a distributed architecture that scaled out much more easily; we never missed a bit; we captured application state perfectly; we could mount backups or convert them to virtual machines.

As the acquisition finalized, Symantec charged us and the BE folks Continue reading →

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 →