Hacker News Reader

Comment by jes | Hacker News Reader

The advice to always batch is at odds with the primary advice of systems like the Toyota Production System (TPS) and Lean, which is to strive for one-piece flow in most places in the system under study.

A continuous integration system doesn’t batch jobs; it starts working on a job the moment it arrives. Would it be better if CI jobs were arranged into batches that were processed, say, twice a day?

I would not want the front desk of a hotel to batch the processing of my request for a room with all the others received in the last hour so that the front desk person can maximize their sense of efficiency.

In seeking to maximize the efficiency of each business operation at the local level, do we wind up harming performance of the company as a whole?

What is the goal?

View on HN

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.

As I read the article, I had the impression that what the author was describing was the kind of activities that they would batch, for example, reviewing pull requests.

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?

Reply on news.ycombinator.com