According to the Theory of Constraints (ToC), every system has exactly one bottleneck that determines the throughput of the overall system. ToC originated with manufacturing, but its results have been observed to be quite general. In the diagram above, the whole process cannot deliver any faster than Station 2 is able to transform its buffer stock of unfinished inventory into its own output. Suppose you make Station 3 run ten times faster than it did last week, leaving everything else the same.
Continue Reading »AI versus Throughput AI Versus Microservices Microservices were always a technical solution to an organizational problem. The Road More Traveled Think back to the early 2010’s and imagine yourself as a startup CEO. You have a vision for a better app or website and you’ve gotten a bunch of VC funding. The trouble is that anywhere between ten and a thousand other startups have very similar ideas. As with any Metcalfe’s law company, at most two of you will survive.
Continue Reading »Constrain the Provider to Liberate Callers Back in the Before Times, I went to a Haskell-flavored FP conference, where one of the speakers said something that blew my mind. Sadly, it seems that I didn’t write this up at the time (although I swear I wrote it somewhere… maybe in an internal company memo) and I’ve lost the details of who said it. If by some quirk of odds, it was you, dear reader, please let me know!
Continue Reading »Rule of Eights The “rule of eights” is a handy way to think about feedback cycle time and the effect it has on human attention spans. This is something I heard–and am probably misremembering to some extent–at an agile conference back in the day. I can’t take credit for this but I also can’t remember who I heard it from. If you know who came up with this, please contact me so I can properly attribute this.
Continue Reading »The Bad Idea Game About ten years ago, I was introduced to something called “The Bad Idea Game” by Danvers Fleury. We were doing a company strategy retreat. Fortunately we did not spend it all on wordcrafting mission and values statements, and we actually engaged in some good strategy. The bad idea game was a fun exercise that didn’t seem to produce any directly useful results. At first I thought it had been a waste of a precious hour from our limited supply.
Continue Reading »Everything We Build Has a Future Cost Suppose we build a road. If we build it road and walk away, it will decay into a hazard before long. It will be scoured by wind, rain, and sand. Ultraviolet rays from the sun will break down its molecular structure. The shifting earth beneath will crack and buckle it. We must maintain what we build, and that requires expense. Suppose we decide that the road is no longer needed or that it costs more to maintain than it is worth.
Continue Reading »Four Meanings of Priorities When trying to communicate, we sometimes use the same word thinking that it means the same thing to everyone. But words are slippery, multivalent things. I can speak a word with one meaning and you might hear it with another. The result is the illusion of communication. As a leader you must be aware that your words can be taken in different ways. In one kind of culture, people might look for the most sinister possible interpretation and assume that’s what you must have meant.
Continue Reading »Transactions Aren't Everything When building an application, we tend to select a database technology based on its transactional characteristics. We consider raw performance, API style, consistency model, data model, and deployment architecture. That’s about as much as your service cares about: can it meet the functional and non-functional requirements for the production behavior of the service? Even in a microservice architecture where no other application is allowed to access the service’s database, that database probably has a bunch of other clients.
Continue Reading »Counterfactuals are not Causality Suppose we’ve had a recent error with a Kubernetes cluster. As often happens with a problem in our systems, we noticed it first in terms of the visible error, which we could state as “Builds did not complete.” Now we want to trace backwards to figure out what happened. A common technique is the “Five Whys” popularized by Lean thinking. So we ask “Why did builds not complete” and we find “Kubernetes could not start the pod, and the operation timed out after 1 hour.
Continue Reading »"Manual" and "Automated" are just words Driving down a shady road, windows down, listening to the frogs and crickets, my family was in the car talking about various stuff and things. This summer evening we happened to talk about the invention and emergence of the word “yeet.” I observed that it was kind of cool to have a word with a known origin and etymology, even if that was only because it was a made-up word. My daughter instantly responded that “all words were made up by someone.
Continue Reading »