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.

I’ve noticed a pattern in much business writing, including technical writing. People feel compelled to label every effect as “pro” or “con”. I think this springs from our primary-school training in persuasive writing. As a result, what should be an engineering analysis often reads like marketing copy. (A related effect, when writing persuasively, people tend to minimize or discount the effects they don’t like. Richard Feymann advised students to be their own harshest critics, to find ways to poke holes in their own arguments.

In the dim reaches of Unix history, the first shell was written. It attached file descriptor 0 as a pipe from the TTY device to a process. That became “stdin”. File descriptor 1 is a pipe from the process out to the TTY. That’s “stdout”. I don’t know when FD 2 became “stderr” but it was early. When you write a Unix program, you don’t have to open these file descriptors.

Without an event, no time passes. This may seem like an odd assertion. You may say, “I can see time passing all around me!” But how do you see it? Do you look at the ticking hands of a clock? In a mechanical clock, each tick is an event: when the tension on an escapement exceeds the friction between its prong and the gear, and the escapement knocks over to the other side with the familiar “tick.

​Architecture​ & Development Require​d Reading ​​Architecture Decision Records​ C4 Model​ (Note: we will only use the first 3 C's.) Accelerate​ ​​​​​Wardley Maps​ Failure Modes and Continuous Resilience Recomm​ended Reading The Principles of Product Development Flow​ Software Architecture in Practice Domain-Driven Design ​Data and Reality, 2ed (Note, the 3rd edition is not as good. Best to stick with 2nd edition.) The Phoenix Project - A novel about IT transformation with a devops flavor.