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.

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.

In discussions about change in a complex system I commonly hear people object, “We can’t do that because X.” (That statement often follows a passive-aggressive prelude such as “That’s all well and good” or “being tactical for a moment.” Depending on your organizational culture you may also hear “That’s great in theory…” Or if your company is more aggressive-aggressive, “Get real!”) My advice is to reformulate that statement. Treat the blocker as a missing prerequisite: “In order to do that, X must be true.

I’ve seen a repeated pattern that plays out in many companies. Delay, or more accurately, the perception of delay induces the creation of “extra” layers in the architecture. The pattern goes like this: A component or subsystem needs to add a capability to serve some end-user need. It will take “too long” to implement that capability in the component. (This is where the perception part really steps in.) Maybe the team is stretched too thinly.

There’s a pattern I’ve observed a few times through scientific and computing history. I think of it as “complexity collapse”. It’s probably related to Kuhn’s paradigm shift. The pattern starts with an approach that worked in the past. Gaps in the approach lead to accretions and additions. These restore the approach to functionality, but at the expense of added complexity. That added complexity at first appears preferable to rebuilding the approach from the ground up.

We’ve talked before about a walking skeleton. That is a fully connected, but not very functional, system that includes all the major integrations. It serves to demonstrate that anything at all can run in the expected topology. But some languages and frameworks ask you to get more correct to form a walking skeleton. Strongly typed languages, frameworks that require you to run from a non “-SNAPSHOT” library version, deployment tools that only fetch from official repositories, etc.

Today, nobody wants to start up a competitor to Amazon. New ecommerce retailers aim at niche markets because Amazon is such a juggernaut and fierce competitor that it would be foolhardy to go against them. Those niche retailers look at Amazon as an exit strategy more than a competitor. Like Microsoft in the 90’s, Amazon isn’t the competition, they’re the environment that any entrant deals with. Competitors emerge when they sense an opportunity to take away market share from a weakened incumbent.

Scaffold or Straightjacket? Douglas Adams’ classic sci-fi comedy novel “The Hitchhiker’s Guide to the Galaxy” opens with a bulldozer approach Arthur Dent’s house. Since Arthur is still inside the house, he is naturally concerned. When Arthur confronts the foreman of the demolition crew, he is informed that his house is to be destroyed to make way for a highway bypass. When discussing the public notice that the local planning office had posted, they have this conversation:

Creating thousands or millions of entities and then deleting them does not return your database to its initial state. Queries won’t show the deleted entities, but operational results can. For example, a table in an RDBMS may have extra storage segments allocated to it. These can generate higher I/O times until someone runs an analyze job to reset the table stats for the query planner. Some databases treat “DELETE FROM USER” very differently from “TRUNCATE USER”.

In “A Philosophy of Software Design,” (ISBN-13: 978-1732102200) John Ousterhout describes the ideal functional interface as “narrow but deep.” That is, it should not expose many methods or functions, but the ones it does expose should be powerful. I have mixed reactions to this principle, so I’d like to explore some examples that support it and others that argue against it. Throughout this section, my lens is malleability. First, imagine a somewhat typical Java domain object with a “broad but shallow” interface.