|
Credit to my colleagues B, B, P, and S for the insights below.
Herding cats. A pointless task. You get ahold of one cat, and the other 19 run off in their own directions. Before you get any cat where you want it, you’ve got to be chasing the other cats that’re getting away. Even if you have ten or twenty friends helping, it’s just you and your doofus friends tripping over cats.
It’s an impossible problem...
…unless…
…you put each cat in its own bag.
That’s the break through!
Once each cat is in its own bag (yes yes yes well accoutremented with snacks, toys, and other cat knick knacks), you can focus on each cat one by one, because the others will stay where they need to be in the meantime.
You pick up its bag, move it from one place to the next, and you don’t have to be worrying about what they other cats are doing. They’re happy in their bags! When you go to get the other cats, the first cat stays nice in its toy filled happy-bag.
Or, if you want to move things along quickly, you can have your friends each take a bag and move the cats simultaneously, in parallel. In fact, if you don’t want all the cats in the same place, it doesn’t matter. Put one cat here, the other cat there.
The bag for the cats is the answer to all your cat-herding problems, but how does this matter in practice?
Cats in bags is what industry leaders do with two-pizza teams, APIs, and containers and all the other tactics of partitioning big problems into many small, manageable pieces.
If you have a team so big that you need twenty pizzas to feed it, then you’ll end up spending so much time coordinating who’s doing what when, how everyone’ll be impacted by what someone else is doing, and how an action here will affect an action there, that you’ll have no time to get anything done. In fact…it better not to get anything done because heaven only knows what the spillover effects will be if anyone actually acts! Big teams? With many and conflicting objectives? You’re herding cats.
However…limit your team size to two pizzas, then you’ve pulled way in the size of problems that each team can tackle, you’ve pulled way in the number of people who have to be coordinated across, and you pull way in the amount of human intellect spent trying to coordinate so that same human intellect can be used to do real work. Two pizza teams? Cats in bags.
Now, if you’ve got two pizza teams, and you want to free people from having to do all this coordinating, then you need (and will benefit from) having clear boundary conditions about how, about what, and when those adjacent teams communicate and coordinate. (Make sure it’s clear about which cat gets which bag, in other words.)
Maintain discipline about those boundaries, and each team can work more or less independently, with only periodic checks that they’re aligned with the system overall (like your cat-bag carrying friends). That's why APIs become so important.
And containerization has a similar ‘modularizing’ effect on the engineered-object, making it way easier for each team to advance its own work without getting overwhelmed with coordinating with all the other teams.
| 
