Wide Awake Developers
  • Counterfactuals are not Causality
    Posted on June 19, 2021

    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
    Posted on October 15, 2020

    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.

    Continue Reading »
  • Blocker? Pre-requisite.
    Posted on September 22, 2020

    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.

    Continue Reading »
  • Delay Induces Lamination
    Posted on September 21, 2020

    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.

    Continue Reading »
  • Complexity Collapse
    Posted on September 20, 2020

    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.

    Continue Reading »
  • Staggering Skeleton
    Posted on September 19, 2020

    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.

    Continue Reading »
  • Weakness Invites Competition
    Posted on September 15, 2020

    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.

    Continue Reading »
  • Scaffold or Straightjacket?
    Posted on August 27, 2020

    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:

    Continue Reading »
  • Deleting From Databases is Not Cleanup
    Posted on August 5, 2020

    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”.

    Continue Reading »
  • Narrow but Deep?
    Posted on July 27, 2020

    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.

    Continue Reading »
back to top

Page 1 of 26

Older »



Powered by Hugo, based on the Er theme.
Copyright (c) 2002 - 2020 Michael T. Nygard