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…