Comment by brookst | Hacker News Reader

Comment by brookst | Hacker News Reader

This keeps getting rediscovered in new domains.

JIT was the savior of manufacturing, until people learned that a single traffic jam that delayed a single delivery could create costs far in excess of the inventory savings.

Optimizations are critical, everywhere. And measuring optimizations is important because it is is easier and cheaper and earlier than measuring end results. Measuring days of inventory, or dollars in inventory, is a pretty good proxy for supply chain efficiency, until covid hits and suddenly “efficiency” means stability rather than minimum costs.

Over and over. Branch prediction / Spectre. Mortgage-Backed Securities. Optimizations based on second- and third-order effects blow up in the real world where any abstraction is approximate.

So it’s not the efficiency that’s the problem, it’s changing the focus from maximizing the desired output to maximizing efficiency, and measuring success based on the performance of efficiency optimizations.

I feel like i have to repeat this very often: if a single traffic jam or other predictable common-cause variation results in your JIT implementation costing "far in excess of inventory savings" all you're telling me is that you have a really shitty JIT implementation.

JIT means having the buffer on hand to handle at the very least common-cause variation. But it also should come with the flexibility to handle variation of assignable causes at a reasonable cost.

Critically, you can't just press delete on all your inventory and then call it JIT. You have to adapt your processes for it, work with local authorities for improvements to infrastructure, and then always keep a larger buffer than you think you need.

JIT is not about deleting inventory. It's about reducing variation in your processes until most of your inventory truly becomes useless.

When you have a good JIT implementation, you are more flexible to take advantage of changing external conditions, not less.

You've now redefined JIT to mean "buffered with the minimum viable buffer" where minimum viable buffer is "whereever I drop the goalposts when defining common-cause variation.

It's the definitional version of working out a variable in an equation, making a mistake, and ending up looking at 0=0.

Happens all the time.

Yes, but that it literally what JIT means, though. It's a mindset of solving assignable-cause variation at its cause rather than papering over it with more inventory.

Literally, "just" in time would mean "not more (material, goods,...) than needed" in time, wouldn't it? A real world analogy to Kanban.

Kanban is indeed one way to do just in time. It's useful primarily for the more variable flows. For more regular flows, you can often rely on the average flow rate working out and schedule deliveries in advance.

JIT is mostly a name for inter-companies Kanban (the factory version of Kanban, not the software one).

And because of that, yes, the amount of inventory is pretty much arbitrary.

This is a common misconception. People often talk about the kanban style JIT because it looks impressive, in some sense. There's all these things going back and forth.

But as Taiichi Ohno himself would tell you: if it looks impressive, it's wasteful. It's a lot of motion with little movement. Efficiency looks disappointingly obvious and simple.

Kanban is a necessary evil when you have been unsuccessful in driving out variation, it's not a desirable state of things.

Yes? My point was that people get carried away with maximizing optimizations because they start measuring the degree of optimization rather than the ultimate goal.

I’m not saying JIT always goes wrong, any more than neural net training always goes wrong. Just that when it does, it is often because an overzealousness that leads to a disconnect between the local and global goals.

> This keeps getting rediscovered in new domains.

I'm not sure there's a need for a "strong version" of Goodhart's law, or I fail to understand the distinction the author is trying to make.

Goodhart is "so true" precisely because it warns about the fact that the measure is often not the goal itself, just like "the map is not the territory", and is indeed an approximation of the goal.

One finds a similar problem with the word "best": best according to which metric? That's how people have different ideas of what is the best.

See footnote 4. I would quote it except it's pretty long and full of links, and an edit, which HN "formatting" would make confusing.

I highly recommend playing the beer game with different inventory sizes, and looking at the results.

Inventory management is not a simple task, and can not be generalized like this. JIT was adopted because it reduced the number of supply chain disasters, not despite increasing it like you claim. But, of course, that reduction wasn't homogeneous and not every single place saw a gain.

I apologize for the unclarity. I was not trying to assert that JIT is fundamentally wrong and always leads to disaster.

My point was that any optimization process can go wrong when people start focusing on maximizing the optimization rather than the ultimate goal. That is how JIT goes wrong. It is also how overfitting appears in neural net training, how security flaws appear in branch prediction, etc.

I'm an MBA. I love JIT. But it's undeniable that JIT has led to disasters. I'm not blaming the approach, I'm blaming specific implementations.

A major consideration people seem to miss when discussing JIT is that it originated in a country with extremely reliable transportation. I had some chance to observe highly resilient and flexible logistical operations in Japan in the 1990s, and have since wondered just how well JIT in the USA follows that model.

The issue with JIT is not so much about proxies as it's about optimizing for the general case at the cost of worst case performance. Things that suppose an inefficiency 99.99% of the time can be an indispensable redundancy or buffer in the face of events that are difficult or impossible to account for.

Reply on news.ycombinator.com