Friday, 14 October 2011

Who are your key men and women?

You have probably noticed that the world of computing lost two important people during the past few days. One was Steve Jobs, without whom Apple just wouldn't be the hugely successful company it is, but also without whom computers may just possibly be still responding to typed instructions (OK: an exaggeration, but you know what I mean).

The other was Dennis Ritchie. Less well known than Jobs but arguably just as important, Ritchie (as you'll know if you followed that link) created the C programming language and co-created Unix. These two things took computers from being a disparate collection of rooms full of machinery attended by white-coated acolytes to the almost invisible devices that permeate our lives.

These two losses got me thinking about what is known as the 'key person' problem. While the loss of Ritchie is sad his death hasn't raised questions like the Quo Vadis Apple that some ask on the departure of Jobs. I don't want to get into a discussion of how Apple will continue without Jobs but the way he ran the company and turned it around make him an archetypal 'key man'.

Sometimes it is the charismatic and very visible head of a company, sometimes it could be the programmer who knows the password to get into a corporate system but hasn't yet got around to sharing it (I recall a possibly apocryphal story about a Norwegian programmer and a tram). What might happen if this person, to use the usual English terminology, 'goes under a bus' or, more likely, becomes unavailable, even temporarily, for some reason such as a hospital visit or a family funeral?

One the one hand there is insurance, which usually addresses business continuity issues for a fixed amount. On the other there are much simpler tactics such as documentation and planning. I have occasionally met programmers who boast that they never need to comment their code. Don't believe them. Comments don't slow down modern code and don't usually waste space. (Big JavaScript libraries like JQuery are a notable exception but even then you can get a long version and an optimised/unreadable one.) Get everyone talking about what they are doing. If you're a one-man-band then think about asking a friend to act as back-stop for you.

Your client will feel more comfortable if you have some system in place to cope with exceptional circumstances and, in most cases, a deal of a day or two while the backup person gets up to speed will not be a problem.