Truck Number Fixed

It's a difficult problem to distribute expertise among project members.

The TruckNumber is the size of the smallest set of people in a project such that, if all of them got hit by a truck, the project would be in trouble.

Thus, a low TruckNumber is bad (1 being the worst), and a high TruckNumber is good (equal to the number of people on the team being the best).

Note: the definition given in TruckNumber is slightly, but fatally, different:

The TruckNumber is the size of the smallest set of people in a project such that, if one of them got hit by a truck, the project would be in trouble.

OlafKummer pointed out that, by this definition, the TruckNumber can never be greater than 1. So I fixed the definition, but left the older one in place because so much of the discussion following it refers to it.

The redefinition turns out to be equivalent to what JezHiggins calls the Smallest Bus Queue Accident.

The redefinition breaks some of what JimCoplien says in TruckNumber. When he talks about a low TruckNumber being good, he's probably thinking about something defined as:

The size of the largest set of people in a project such that, if one of them got hit by a truck, the project would be in trouble.

As for external consistency, JohnWashburn? also points out that DoInspections treats increasing the TruckNumber as a Good Thing -- i.e. as if it were Smallest Bus Queue Accident, which is equivalent to the above redefinition.

--GeorgePaci

Some comments about the "smallest group such that if all the members of it were hit by a truck, the project would be in trouble" definition: Note that, in effect, the truck gets to pick who it will hit.

A related metric, then, would allow the project to pick who will be hit: "the largest group such that if all the members of it were hit by a truck, the project would still not be in trouble".

As with the truck-gets-to-pick definition, smaller is still worse and larger is still better (though the min is now 0 -- and what's now the truck number for a project that is already in trouble?).

So the Idea Champion example above has the value 1 for the first definition, but presumably between 1 and n-1 for the second.

For a more mathematical treatment, see MoreFunWithTruckNumbers.

-- GeorgePaci

What about the team with only one competent person? Then the max truck number would be team size - 1, but this isn't a good thing. [ERROR: Number is actually 1]

One competent person is the IdeaChampion, perhaps. Anyway, if there is only one competent person on the project then somebody didn't do his homework right.

I describe this concept to the boss as the project being "bus and fire-proof", which I translate for him as "if I get hit by a bus, or you decide to fire me, the project goes on".

--TrippLilley?

Been thinking about this recently. I've always thought of TruckNumber like this: If X people got hit by a truck, would the project be in trouble? Substitute any number for X, and you have a 'yes' or 'no' for that number. The TruckNumber, then is the smallest number whose answer to the question is 'yes'.

However, it really depends who gets hit. The usual assumption is that you go for the WorstCaseScenario?, but what if we instead treated it like one of those first-year statistics courses? Restate the question as: If X randomly chosen people got hit by a truck, what is the probability that the project would be in trouble? For each number X, you can determine the probability using standard stats calculations, which means you can also determine the 'expected' TruckNumber. The 'worst-case' TruckNumber then is the smallest number whose answer to the question is a non-zero probability. Of course, you'd like this number to be as high as possible, but it might also be worthwhile to try to raise the expected TruckNumber even if the worst-case doesn't improve.

Example, on a team of 4, with one person who knows everything and 3 others who are all expendable, the worst-case TruckNumber is 1, but the expected TruckNumber is 2.5.

Example, on a project with 4 people and 2 modules:

      1  2
 Amy  Y  N
 Bob  N  Y
 Cal  Y  N
 Don  N  Y

The worst-case TruckNumber is 2, but the expected TruckNumber is 2.67. If Amy were to learn module 2, the worst-case would remain 2, but the expected TruckNumber would improve to 3.0833.

Sorry, but Truck Numbers are always integers. You have to round up (or down, depending on the definition you use) to the next integer, since people don't come in decimal increments.

Expected TruckNumber is just a trick to make you feel better about your true TruckNumber. As an absurd proof, your actual situation isn't improved by hiring the entire population of China. Your expected truck number is now 600M, but you are still screwed if your key people are hit by a truck. Expected TruckNumber is about as useful as the average number of toes per employee.

I agree that adding people to a project is not a good usage of the ETN idea, but the fact that you can incrementally improve ETN by training people (where standard TN would indicate no improvement) is what makes it useful. Given a fixed team size, anything you do to improve ETN is worthwhile, even if your standard TN is the same. It's like BigOhNotation and QuickSort. QS is O(n^2), but it is expected O(n log n).

How about a TruckPercentage?? This would be the Trucknumber of your team, divided by the size of your team. Thus a TruckPercentage? of 1 is good (the whole team needs to be wiped away for the project to be in danger), while your TruckPercentage? approaching zero would be bad. -- AalbertTorsius. Reading this some years later, I realise I was talking about either a TruckFactor or I meant a TruckPercentage? of 100, not 1. --ATS.

Here's a relevant story: http://www.folklore.org/StoryView.py?project=Macintosh&story=I_Still_Remember_Regions.txt Ah, FolkloreOrg.

See: TruckNumber, MoreFunWithTruckNumbers

I think that most projects would be in trouble if even one person were hit by a truck or otherwise left the project. It might be more useful to measure how much trouble the project would be in if one person were hit, e.g., the most critical person. In other words, the level of dependency on one person.

Even when no one gets hit by a truck, many projects end up in trouble. Sometimes because one person becomes a bottleneck. Improving the level-of-dependency-on-one-person number would be useful there too. Because, when there is more cross-training and less dependency on one person, the team is more able to accept some new members more quickly to try to get out of trouble. In other words, Brooks's Law applies even more when only one or a few people hold key knowledge.