Systems and Delays

where delays are shown to be counterintuitive.

Leaving the house (and the country) for a week or two during the holiday season is a great time to get out of my stereotypical ways of passing free time (entirely too much YouTube, Lobste.rs, HackerNews and BlueSky) and try something else.

For my recent vacation I have packed some grid paper to make a bitmap font, and two books: the first one was Nachové pustiny: a Czech post-apocalyptic novel to get some inspiration for my “Fallout but in Czech Republic” MMO game, and the other was Thinking in Systems: a book recommended at work (and bought with my work education budget) which was collecting dust in my bookshelf for a good few months now.

I’m happy to announce I managed to get through all three of these goals: I’ve created a bitmap font (though I still have kerning and accents to go through), devoured the post-apo novel (it was okay), and got through the systems book!

Thinking in Systems introduces a framework and a visual language of sources and sinks, stocks and flows, feedback loops and systems that (more often than not) emerge bottom-up from them.

It all roughly corresponds to mathematical models and differential equations, though the book doesn’t go into detail of those and only mentions the actual formulas for its examples in an appendix.

Delays are weird

There was one really cool chapter that IMHO is the highlight of the whole book. It concerns delays.

The running example is a car dealership manager shepherding a stock of cars on their parking lot, aiming for it to always be 10x the amount of cars sold. When the customer demand rises, she starts ordering more cars to cover the gap.

Delay-less system

In an ideal world there are no delays: she immediately sees an increased demand and the discrepancy between the current stock and the ideal one, she immediately sends an order to bring more cars in, and the cars immediately arrive.

Also, in this example the time granularity is days, so imagine that at the end of the day she sees 30 cars got sold, sends an order for 30 cars and they arrive the next morning.

Let’s first see the constants in our model that won’t be affected by the delays:

The customer demand starts at 20 cars each day, then ramps up to 22 cars each day, with a spike of 70 cars on one specific day.

Sales are min(customer demand, inventory), which in all examples below will equal customer demand, as we have enough cars ready, but you can imagine getting out of stock if demand gets high enough fast enough.

Our manager calculates the desired inventory as sales * 10.

This model has no delays, but it has an issue with overreacting to the random spikes in customer demand by buying too many cars which then take forever to sell, and more importantly it’s unrealistic: in the real world everything has a bit of a delay. The orders take time to process, the cars take time to arrive at the dealership lot, and so on. We’ll call that the delivery delay.

That seems like a bad delay, but delays don’t need to always be bad: consider that the manager might want to not overreact to those random spikes. She had ordered 550 cars because of a spike, when she normally orders only around 20 a day! Instead she might want to get to the desired inventory slowly over time by ordering only half of the discrepancy, or a third, etc. Let’s call this divisor the response delay.

System with delays

Let’s run the model with these two delays and see:

• delivery delay: 5 days (from sending the order to the cars arriving on the lot)
• response delay divisor: 2 (if missing 30 cars, order 15 today.)

The combination of the two delays made our system oscillate! It never stabilizes even if the customer demand remains constant afterwards.

The manager is caught in a cycle of ordering too many cars, then ordering more the following days before the first order arrives. Once orders arrive, she has too many cars and stops ordering. But then inventory dips again and the cycle restarts.

Shorter delays: surely the fix?

Let's try shortening the response delay:

• delivery delay: 5 days
• response delay divisor: 1 (buy exact missing amount at end of day)

Trying to be faster made things worse: inventory oscillates much more violently (shooting up from 132 to 518). This is even worse than the no-delays scenario.

Longer delays: Take it easy...

Let's simulate a more patient manager by making the response delay divisor larger (6). When missing 30 cars, order just 5.

• delivery delay: 5 days
• response delay divisor: 6 (slower response! longer delay!)

The oscillations died out and stabilized!

Conclusion

Delays intuitively seem like something you want to minimize. But here, shortening a delay made things worse and making it longer made things more predictable and less wasteful.

Make a model of your system, try different parameters, and see how it behaves based on data rather than intuition.