More Fun With Truck Numbers

This page has nothing to do with a variation on TrainSpotting.

Go read TruckNumber and TruckNumberFixed first.

Since there are two quantifiers involved in most of the definitions proposed for TruckNumber, I find thinking about them in terms of adversarial games to be helpful.

You could also think of them in terms of satisfying boolean formulas: the proposition labeled X means that the person named X got hit by a truck. A project where A is the only person who knows about one area of the project, and B and C similarly have their own exclusive domain, can then be characterized by the formula "A | B | C" - that is, any assignment of truck hits that satisfies this formula puts the project in trouble.

If we have an Idea Champion I and a couple of interchangeable developers, we get: "I | (A & B & C & D)" - that is, either I or everyone else has to get hit by a truck to put the project in trouble. Clearly, the truck will pick I.

This is a flaw in the definition. Clearly a project with one indispensable member will be safer than one where everyone is indispensable.

Go back to the independent experts case: "A | B | C | D". If we have everyone pair up (A with B, C with D) and teach the other of the pair their areas, we get: "(A & B) | (B & A) | (C & D) | (D & C)", which simplifies to: "(A & B) | (C & D)" . The TruckNumber is now 2, instead of 1.

Note how the clauses of the top-level disjunction correspond to tasks, and the propositions in each task's conjunction correspond to the people that know about the area. In other words, the truck has to wipe out knowledge of at least one area, and it has to hit everyone with that knowledge to do so. Also note how cross-training has effectively (in some sense) merged four specialized areas into two.

Now if we have B and C pair up and cross-train, we get: "(A & B & C) | (B & C & D)". The TruckNumber is now up to 3, since the minimal conjunction has three terms.

Finally, if all four people know all four areas, the truck number is four: "A & B & C & D".

For a different perspective, if each person teaches the next person their area, we get: "(A & B) | (B & C) | (C & D) | (D & A)". The TruckNumber is 2.

-- GeorgePaci

This is part of what I wrote before slightly editing George's writing. If anyone thinks it is of any value, it can be left here. If not, someone can delete it. Thanks! Thanks for fixing the stuff I left unclear. -- GeorgePaci

You're welcome. You did not leave much unclear; it was just the last paragraph that threw me a little - I probably went overboard with the editing. -- RandyKramer

If I followed the discussion properly (and extrapolating from three to four), first there were four experts in independent areas of the project. Losing any one of them means the project is in trouble. Truck number = 1.

Then, A and B learned each other's area, and C and D learned each other's area. For the project to be in trouble we have to lose A and B (2) or C and D (2). Truck number = 2.

Then C learns A's and B's areas, and B learns C's and D's areas. For the project to be in trouble we have to lose A and B and C (3) or C and D and B (3). Truck number = 3.

Finally, A and B and C teach D their areas, and B and C and D teach A their areas. Now all four people know all areas. For the project to be in trouble we have to lose all four people. Truck number = 4. -- RhKramer?

The fact that (A&B) | (B&C) | (C&D) | (D&A) has the same TruckNumber as (A&B) | (C&D) seems to me to indicate a (perhaps minor) weakness in the definition of TruckNumber. The former is clearly more fragile than the latter. See the TruckNumber page itself for some verbose comments on one rather painful way to improve on this (at the cost of having a much less comprehensible and convenient metric). I've just thought of an interesting way to think about this stuff, but I need to think harder before trying to put it into words... -- GarethMcCaughan

The former is indeed more fragile than the latter. In other words, there is a set of people the truck could hit (say {B,C}) that puts the former in trouble, but not the latter; but there is no set that would put the latter in trouble without putting the former in trouble.

Actually, the TruckNumber of (A&B) | (B&C) | (C&D) | (D&A) is 3. If A gets wiped out, B and D still know how to do A's stuff. That extends to B through D without loss of generality. Therefore, A, B, and D must all be wiped out in order for the component that A was indispensable for to be lost. -- KaelLizak

No. The TruckNumber of (A&B) | (B&C) | (C&D) | (D&A) is 2. If A get wiped out, B and D still know parts of A's stuff. If B gets wiped, the knowledge of Topic 1 is lost. D knows about Topic 4, but that is not enough. (A&B) | (B&C) | (C&D) | (D&A) is 'neither more robust nor mor fragile than (A&B) | (C&D). -- GregorRayman

This is seems to miss some subtleties: to start with, there were 4 areas of knowledge/expertise, each mastered by one team member: A -> Ka, B -> Kb, C -> Kc, D -> Kd.

Then the groups (A, B), and (C, D) cross-train. We have (A, B) -> Ka, (B, A) -> Kb, (C, D) -> Kc and (D, C) -> Kd in the original description, or (A, B) -> Ka, (B, C) -> Kb, (C, D) -> Kc and (D, A) -> Kd. Thus, _any two_ members of the team cause damage to the project. The apparent extra resilience results from the fact that each member is closer (shares competence with) at least one team member who has mastered that area.

In the real world, things are made more complicated because sometimes it may not be sensible to share skills: an Oracle DBA will not normally be asked to cross-train in interface design. -- KieranBarry? --- But this is because, according to the above (correct) definition of TruckNumber, you only get to pick the size of the set, and the truck gets to pick the actual people. So you pick two, thinking {B,C}, and the truck goes ahead and flattens {A,B}.

You can probably express this difference in fragility with another metric:

The maximum number of people who can get hit by a truck and still not have the project be in trouble.

The problem with this definition is that you can lower the number by simply adding useless members to the team. A company with a large "management overhead" would do really well on this score. Obviously having extra people along for the ride doesn't make the project any safer in reality

(Somebody name this metric if it doesn't already have one.)

How about BlastRadiusNumber?? Of course that still doesn't address the issue of the overall complex factor that we're trying to measure. We need some kind of DepthAndRedundancyFactor? formula for determining how many people are actually on a project and how many of them are critical to the project's success. Hmm...this could get a bit tricky.

This metric is different from TruckNumber in that you (not the Truck) get to pick. It is guaranteed to always be at least as large as TruckNumber.

Of course, this metric has its shortcomings, too: in the example of the single indispensable person and all other team members being interchangeable, this metric returns n-1, where n is the size of the team. This looks good, but the situation is actually very fragile.

Actually, in that case the (fixed) truck number is one, since that one person is indispensable. It's the smallest set of people in a project such that, if all got hit by a truck, the project would be in trouble. (We call it a BusNumber hereabouts.) -- KaelLizak

Maybe the probabilistic approach being developed over at TruckNumber is the only practical way to proceed. But you do need to take into account that indispensable people are more likely to get hit by certain kinds of truck (e.g. the higher-salary-from-a-competitor truck). -- GeorgePaci

That last threat is always present. Any project worth a hill of beans is going to draw the kind of workforce that is susceptible to a RaidFromCompetitor?. I don't see how you can possibly avoid that; the TruckNumber calculations only help to mitigate the inevitable damage caused by that kind of truck. So, the BlastRadiusNumber? also comes into play. How many people on the project came on board because of the one guy being wooed by the competitor? How will the defector affect the other team members when he tells them his new salary? How many developers is the competitor looking to grab out of your staff? Like I said, blast radius. (I'll avoid other similes like CEP.)

How about CollateralDamage? instead of blast radius. The latter has geometric connotations that I find unpleasant in this context.

Also, this is all about identifying risks and quantifying them so as to assess their effects. Hopefully this will lead to a mitigation strategy. However, one important point that this metric misses is a probability factor. To do this I think that we may need to list common classes of 'Truck'. We can then assign probabilities, on a per project level, of each truck choosing to drain our resource pool. TypesOfTruck? anyone? -- BryanDollery

Nah - we don't really need to ID the types of truck. It doesn't matter too much, since the truck - whichever type - gets to choose which team member(s) it goes after. I agree that we need some mechanism for evaluating exposure as an overall factor, but to claim that a project is not exposed to one type of truck or another is probably false complacency. The truck that comes barreling out of the alley is the one we have to watch out for.

So why do you have people on your project that are unnecessary?

There are many reasons why you could have people on a project that are unnecessary to the project's completion. It could be part of the training of new team members, or it could just be to add resilience by exposing more people to the project knowledge. I have worked in locations where there were weekly meetings between different project groups just to spread the knowledge, so that people could be moved between groups easily if a disaster happened.

Of course most of the non-indispensable people on a project are not unnecessary, it is just that another resource could be substituted without too great a difficulty.

Why worry about BlastRadiusNumber? / CollateralDamage??

The two metrics tend to depend on the type of analysis being done. The typical TruckNumber, with the truck picking the targets, is fine for trucks like RaidFromCompetitor? truck or SickAndTiredOfThisJob? truck. However, it may be highly useful for upper management to take a look at the CollateralDamage? number to determine how long they wish to rent the ReduceProgrammerOverhead? truck. Another way you can look at this other metric is as a listing of how many people you can SAFELY remove without endangering the project.

I think we are searching for the term conditional probability.

P( project in trouble | R people hit by truck )

For a project the solution is a vector of numbers, better / worse, is meaningless unless we can also state P( R people hit by truck ) Eg: What is the point in worrying about a particular 2 people getting hit by a truck, and being in deep trouble, when many (all) combinations of 3 people are a problem. P(3 people hit) may be 100 times lower (0.01^3) but 50 C 3, (50*49*48/2/3) is largish.

Computing P( project in trouble | R people hit by truck ) is most directly achieved by

This also allows us to weight by size of trouble.

This also allows us to weight by individual and joint probabilites of being hit by a truck.

Friends who ski together on the weekends, who also form a truck number are a clear risk.

Note: If you start down this detailed and intricate path of analysis, then

In other words:

Truck number,

Contributors: GeorgePaci, RandyKramer, GarethMcCaughan, BryanDollery, MartySchrader, EricWilleke

EditText of this page (last edited November 3, 2014) or FindPage with title or text search