I spoze we should talk about scaling.
There are a bunch of branded solutions to the puzzle of how to organize development of large apps with large teams. I don’t know of one that is worth the bits consumed in its logo.
Yesterday I mentioned assumption-boxing, that’s when we express a problem in such a way that we bind ourselves to one or a small family of possible solutions. The assumption in all the scaling brands I’ve seen: that effectively writing large-scale software requires hierarchical control.
The core of the idea is that if we don’t have a hierarchical control structure, we will make mistakes.
Fairly early on, I stopped spanking the kids in my life. My lovely wife taught me to do this. My argument was, "If you don’t spank, the kids will be completely out of control." Her argument was, "Absolutely correct. Also if you do spank them." Her point was simply that "completely out of control" is pretty much what kids are. Bouncing w/energy, pushing every button, learning. Not only is there really no stopping that, but we don’t want to stop it. At most, we want to aim it at places where it doesn’t do much harm.
If you don’t have hierarchical control, teams will make mistakes. Also, if you do have hierarchical control. There’s no stopping the making of mistakes, and we don’t even want to stop it.
The problem morphs. "How do I prevent teams making mistakes?" becomes "How do I get mistakes to happen in ways that don’t do much harm?" You have a couple hundred people and a big app to write. I have some advice.
Adopt a strong stance that team rotation is desirable, and support it actively. Study the work of Heidi Helfand to get some clues.
Focus your training not on change prevention technique but on change enabling technique. TDD, feature flags, versioning, self-describing interfaces, side-by-side-ing, continuous integration & deployment.
Give most of your love to today’s product and today’s story, and gradiently less to next week’s, month’s, or (shudder) year’s. Find something — anything — that makes your user’s life better, and SHIP IT RIGHT NOW. Aim to do this every day or two.
Take steps. Tiny steps. Over and over again. Never’s a long time, but basically, never make great big changes. This applies even to the advice I’m giving you now. Encourage any step that a) is doable, and b) is undoable, and c) is not clearly the opposite direction from where you want to go.
This is how you get largescale teams building largescale apps. Not by re-creating the known-fail static hierarchical control model.
- Dynamic re-teaming
- Change-enabling technique
- Fisheye focus
- Tiny doable undoable not-clearly-wrong steps