3 min read


When I first started building the simulation, I intended to model what I thought was a simple scenario: a CI pipeline with a given level of risk in each stage. My intent was to explore the impact of batch sizes on cycle time.

Ironically, I still have not built out that exact scenario.

It sounded so simple, but as with all things the devil is in the details. When I first started coding the scenario, things moved along so quickly that I assumed I would have a working model within a few days. But with each step I took, the path ahead seemed to stretch forward another two steps. The end that seemed so near at the beginning danced like a mirage, receding faster than I progressed.

I needed to do something simpler.

Maybe I could just model a single build instead of a whole pipeline? No, I needed something even simpler than that. Even modeling a single build would involve coding workers and features and bugs and batches and tests that passed or failed. They’re all capabilities the simulation engine has now, but back when I started it was far too much to do all at once.

Then I remembered Eliyahu M. Goldratt’s matchstick game from his classic book The Goal. In it, work flows through a chain of dependencies based on the roll of a six-sided die. Work doesn’t pass or fail. There are no bugs or fixes. There is just a single stream of work flowing forward through a series of workers.

The game isn’t really a game in the sense of making choices and forming a strategy. Your fate is determined entirely by a roll of the dice. The point is to illustrate how much lower the productivity of the chain of workers is than most people’s intuition says it should be. Learning the ways in which intuition leads us astray is extremely useful. But once you get the point, the game is no longer fun to play.

The subsequent simulation scenarios I’ve created are different: they emphasize tradeoffs.

The tester bug scenario involves a tradeoff between personal gain and team success. You decide whether or not to file bug reports for things that may or may not actually be bugs. If you don’t file enough bugs, you fail to meet your bug quota. If you do file the extra bug reports, the whole team could fail to ship the release. (Yes, that’s terribly dysfunctional. That particular scenario is not modeling a healthy system.)

The developer support scenario I wrote about a couple weeks ago  involves a tradeoff between meeting a deadline and being responsive. You have numerous parameters you can tweak, but ultimately you end up optimizing for delivery or responsiveness, not both.

The real world is full of such tradeoffs.

In fact, everything is a tradeoff. Every decision you make may address one set of concerns but at the expense of others. There are no perfect decisions that make all problems go away. The very best anyone can do, at work or in life, is choose which problems to have.

Do you want the problems that come with blowing a deadline? Or with disappointing internal stakeholders? Or with trying to satisfy both and not quite satisfying either? Whatever name I finally settle on for the simulation will have to give a nod to that notion of tradeoffs because that’s at the core of every scenario I imagine building.

And there are so many more scenarios to model: tradeoffs between speed and risk and organizational resiliency and revenue and cost and customer satisfaction and employee morale.

I’m taking it one scenario at a time so I have plenty of opportunity for feedback and learning. That choice, to build one scenario at a time, is itself a tradeoff. It’s one I’m making quite intentionally. I’d much rather have the problems that come from moving too slowly than the problems that come from being heads down for too long working quickly but in a vacuum.

Simulation Demos and Early Access

If you are interested in seeing a demo of the simulation, it’s not too late. I have open slots for demos next week and beyond. (Worth reiterating: this is an exploratory conversation and most definitely NOT a sales call. There is nothing to buy. Although part of my goal with these demos is to gain insight into what aspects of the simulation could be a valuable product, I have nothing to sell you.)

In addition, there is now a preview of the demo scenario available online. If you are interested in taking it for a spin, you’ll still need to sign up for a demo first for now since the UI is not exactly user-friendly. If you’ve already seen the demo and would like to play with the scenario you saw, please email me at quack@curiousduck.io. (The need to see a demo before you get access is temporary. I hope to have a publicly available version that's self explanatory in the not too distant future.)

Next Up

In addition to the simulation needing some UI work, the performance is not where it needs to be if more than a few people are going to run it simultaneously. Over the next week I will be experimenting with changes to the architecture to support performance and scalability. That will unblock making the scenario truly publicly available.

Stay Curious,