… then three come along at once.

The term bus factor (or truck number) is one which I’ve come across before joining the wonderful world of XP.

The best definition I’ve found is here, but briefly it’s the smallest number of people whose demise at the wheels of a rogue bus (or truck) would put a project in trouble. In an ideal world, any project would be so easily understandable that even if an entire team were to disappear, another team would be able to step in and smoothly pick up from where they left off. Unfortunately things are never ideal, and our bus factor here could be better.

Bus Magnets

Fate has a way of fulfilling itself for those who taunt it. Terry Pratchett mentioned that standing “on a hilltop in a thunderstorm wearing wet copper armour and shouting ‘All gods are bastards’” wasn’t the smartest idea in the Discworld. Don’t do it on projects either, or the bus will come careening down on you when you least expect it. Here are some bus magnets I’ve seen.

  • Undocumented, illegible, incomprehensible code.
  • Project attrition, which reduces the number of individuals with a particular expertise.
  • Blame cultures, which make people hang onto their knowledge instead of sharing it in order to protect their job.
  • Blame cultures, which make people avow all knowledge of a problematic area in order to avoid having to deal with it, thus protecting their job.
  • Poor working environments, which make good people (who usually have all the knowledge) leave.
  • Unrealistic time constraints, which mean code is more likely to be hurried, therefore illegible and undocumented.
  • Unrealistic time constraints, which mean code is more likely to stay illegible and undocumented.
  • Perfectly working code. It doesn’t get talked about, so as attrition occurs, so does knowledge.

Unfortunately, attrition (or rotation) is required to stop people being bored, and working code is an important stage on the road to customer satisfaction. However, there are a couple of things which can be done to minimise or alleviate all these problems, and reduce the probability of your project being terminated by a bus.

Bus Buffers

  • Write code legibly. Spend some time thinking about the wording; in comments, if you include them, and in the names of variables, methods, classes, packages and associated files.
  • Be consistent in the wording between domain and code. (JBehave!)
  • Say no to blame cultures. (Have I said this before?)
  • Keep a happy working environment and ensure that people care about the success of their project (see XP Explained).
  • Pair program! Particularly, make sure the newbies (like me) pair with the experienced people. Encourage the experienced people to treat the newbies with respect, and to have patience with them. We are the future.
  • If something hasn’t been changed for a while, and seems to be working perfectly, document it. Even if it’s just a couple of lines on a Wiki. Remember to update or remove the documentation if it changes – erroneous documentation is worse than none at all.
  • Be realistic about time constraints. Encourage customers to be realistic too; they don’t want to end up with shoddy code any more than you do.
  • Keep people who’ve rolled off a project available for consultation where possible.

Of course, there’s one group of people whose demise would absolutely mean the end of the project – the customers. If you care about your project’s success, I guess you should care about theirs, too. It doesn’t just end with getting paid.

This post has been spawned as a result of being asked more and more for expertise I simply don’t have. Some of the best people have already left, and I’ve tripped over a couple of gaps in the knowledge pool. I guess it happens, even on projects as exciting as mine.

Less time blogging, more time pairing…

This entry was posted in Uncategorized. Bookmark the permalink.

8 Responses to … then three come along at once.

  1. boryon says:

    Another one to add to the list of bus magnets:
    Management being unwilling to refactor code that just about works, but is poor code.

  2. sirenian says:

    I think it might be because they can see the end of the project coming up, or because there are unrealistic time constraints. They’ll learn. One day everyone will be doing the Agile thang. Less adaptable species will die out.

  3. boryon says:

    Nah – remember I’ve mostly worked for ‘product’ companies.

    It’s more a case of ‘if it isn’t broke, don’t fix it’, combined with not realising things are broken.

  4. sirenian says:

    Tests for everything… that way, if it ain’t broken, you can fix it and still know it ain’t broken. I love Test Driven Design (or even better, Behaviour Driven Design).

    Look what they’ve done to me. I’m a geek.

  5. sirenian says:

    You’re right. Google has horses, lawnmowers, vacuum cleaners, motorbikes, MP3 players, weather phenomena, jackpot combinations and stories called “Silver Bullet”, but no actual silver bullets.

  6. boryon says:

    Heh, yeah. I’m sitting here writing a bit of code thinking to myself:
    This would be so much easier if I’d specced out a full set of unit tests

    Unfortunately, I seem to be ahead of most of my company in that:
    a. I do thorough unit tests
    b. I keep my tests so they can be repeated

  7. sirenian says:

    Be proactive. Be enthusiastic! Make them do it too. Or go play in the snow. Your choice.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s