Hair-Raising Words

My daughter just got back from touring a “haunted circus” with her friends. She reports that the clowns were terrifying. (For those who aren’t living in North America, the Halloween holiday is a time when the macabre and spooky are in vogue.)

Coulrophobia–the fear of clowns. Image credit: Graeme Maclean (Wikimedia Commons).

Well, I’m a programmer; I can get chills down my spine without paying an entrance fee. All I have to do is go to a meeting where certain words get tossed around casually. Blood drains from my face; my heart starts racing; visions of apocalypse dance before my eyes.

Okay, maybe I’m exaggerating a teeny bit–but I have found a few words that have a near-magical capacity to provoke stress, worry, and miscommunication in companies that make software. Here is my short list: Continue reading

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) {
  doIt();
}

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:

prepare();
doIt();

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

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

What Should Be In The Next C++ Compiler?

Herb Sutter (champion of VC++ compiler evolution at Microsoft) posted an interesting poll today. He wants to know what the C++ developer community thinks about priorities for the next release.

Go vote.

Editorial comment: I’m not surprised that conformance is winning over performance or fancy features. MS’s compiler has always been easy to use in a vacuum, but a pain when interoperability and cross-platform matter. When Herb went to MS, things improved drastically, but my perception is that gcc leapfrogged VC++ a year or two back, as C++11 began to gel. (VS 2012 probably gets back to parity again; I haven’t poked into it deeply, yet.)