While chatting with some acquaintances today, I found out that not many people are familiar with the concept of truck number.
The truck number of a software developement project may be informally defined as “the number of team members of your project that have to be run over by a truck in order to have your project going to the dogs”.
Obviously, “being run over by a truck” is just a cheeky figure of speech; in reality it may be a developer resigning with no advance notice, or with sudden, serious health problems, etc. So the Truck Number is really one of the measures of risk associated with your project’s personnel.
As Cockburn and Williams notice, the worst truck number your project can have is “one”: if, for example, you have only one person with deep knowlegde of a vital subsystem, or only one who knows the in-and-outs of your architecture, your project is in serious trouble if you suddenly lose this person.
So, as a measure of risk mitigation, you should strive to have the highest truck number possible. Cockburn and Williams propose Pair Programming as a solution to this problem, but other solutions may be equally valid: daily meetings, better documentation, etc.
Update: the first definition I wrote wasn’t so clear, so I re-wrote it.
Iscriviti a:
Commenti sul post (Atom)
2 commenti:
I think that the truck number is a wrong-headed measure in programming. If the number is ever close to one, you don’t have a personnel or information sharing problem – you’ve a code problem. Focusing on sharing information above the amount required for others to get their work done is, by definition, a drag. A codebase that will be unmaintainable when its author suddenly leaves is bad code.
At my company, I strong believe that the number is very high, and yet many (probably most) parts of our codebase are written and maintained by just one person.
Patrick:
Good point, but while I think a good codebase is a requisite and may facilitate having a higher truck number, I don’t think it can be used as a risk mitigation strategy when you have a low truck number.
Let’s make an example: a development team has a strict deadline to deliver a product - if they miss it, the team is in serious trouble. One day one of the developers - the one who produces the best code in the team - gets hit by a truck. Will the substitute (either a new developer, or another team member) be able to grasp the code and produce new code before the deadline? If no, then it means that the project’s truck number is one and now the project is compromised.
Posta un commento