|
|
|
|
|
|
by sj4nz
1982 days ago
|
|
|
I think this confuses manufacturing/operations and problem solving/analysis. In manufacturing and operations, the thinking has already been "baked" into the activity and you make it faster by adding more people, materials and equipment. (More cashiers, more assembly lines, more factories, more CI compute/memory/storage/bandwidth) With problem solving/analysis context switching would exhaust concentration from the thrashing of unrelated patterns/predictions. If you add more people to a problem solving/analysis context you increase the amount of coordination work for everyone to achieve "shared understanding". If you add a _lot_ of people to a problem solving/analysis context (e.g. open source/crowd sourcing) you throw out the constraint of "shared understanding" and win by probability with many different minds partially thinking about the problem. This takes longer of course-- because the project maintainers then have to sift through the crowd's input. The goal has to be understand the form of work, and adjust the levers accordingly. |
|
|
That sounds more like part of the work involved in manufacturing software than what you refer to as problem solving / analysis.
What if the author decided to batch the processing of pull requests so that they processed all of their outstanding PRs once per week?
Would that be a good thing for the rest of the team? What if you're trying to deliver an important fix and your PR is stuck in queue waiting for Friday to roll around before the author gets around to review it?
The late Colonel John Boyd made important observations as to the competitive advantages that accrue to organizations that can move quickly and well-enough to accomplish the mission.
I certainly could be wrong, but batching everything, as the author seems to be suggesting, sounds like a recipe for an organization that is slow as molasses in January, but also populated with people who see themselves as being highly efficient.
What am I not seeing?