architecture

Data Sinks and Logic Floats

In effective layered architectures, data sinks to the bottom, and logic floats to the top. The more narrowly-scoped the logic, the higher it floats. The more permanent the data, the deeper it sinks.

safety-ii

Advanced Blamelessness is Owning Mistakes without Fear

Blame happens when we stop our investigation with operator error. Then James restarted the server, which broke everything. The first step towards a blameless culture is to stop blaming people for things going wrong. (Assuming no malicious actors.) Then I restarted the server, which I should've known was

culture

What do you mean by "bad" software?

(Before I get started, a moment to appreciate this header image and whatever was the genesis of it.) Engineers will often describe software as "bad"—often with words like "terrible" or "shitty." This invective is hurled at languages like PHP and JavaScript, at frameworks

teams

Distributed Teams Need Face Time

There's a genre of post I've seen on LinkedIn and the fediverse recently that goes something like "I worked with people in person again and forgot how great it felt!" In the warming discourse about remote work and Return To Office (RTO) policies, I

ip

There's a Difference between "Publicly Available" and "Free as in Speech"

A couple weeks ago, the Wall Street Journal published 10-minute interview with Mira Murati, CTO of OpenAI, in which Murati said that their new "Sora" video generator model was trained on "publicly available or licensed data" (emphasis added by Ed Zitron). Ed wrote a longer piece

stuff i read

Stuff I've Been Reading - March 1, 2024

This is a collection of some of the articles, blog posts, podcasts, etc, that I've read in the past couple of weeks. I'm hoping to make this more of a weekly post on Fridays. We'll see! I'm immediately going to break the

planning

Debt, Depreciation, and Sustaining Engineering Work

Calling rearchitecture "tech debt" is a dangerous lie: it misrepresents the level of effort and retroactively makes our decisions into mistakes.

architecture

Starring our Monolith in the Role of...

Stop me if you've heard this one before. As a small, early stage start-up, we built an application in [Rails / Django / Express / Gin] because we were able to lean on the framework and ecosystem for a lot of the boring stuff, and focus on our unique value. Now,

Code

Introducing API Boundaries to Prepare for Bigger Changes

Alternatively: API Boundaries for Fun and Profit I routinely misquote Kent Beck, who said "for each desired change, make the change easy (warning: this may be hard), then make the easy change." He said this on Twitter (RIP) so I won't be linking to it, but

continuous deployment

When to use Feature Flags: Extra-Ordinary Unconfidence

Feature flags are a sine qua non for effective Continuous Deployment (CD)—and yet, they aren't always necessary. Nearly every sprint I've observed for the past 10 years has included the question "should this be feature-flagged?" at least once. Such a common question deserves

Code

Code is Knowledge

In the mid-2000s (so, in ancient history) a friend of mine went to an interview at a big tech company and was asked to write the JPEG compression algorithm on a whiteboard. He didn't know that algorithm off the top of his head, which he admitted, and then

programming

Using Timers to Learn

When I'm trying to learn a new language or environment, one of the first things that I try to do is implement a timer: code that can be used to instrument other code and print out how long it took to run. A long time ago, early on

go

Go Interfaces as Requirements, not Capabilities

This is a hard-won lesson that's taken me many years to learn, and I have seen others follow a similar path, so I'm writing it down in hopes that maybe some people will find a shortcut. Go's type system is, in my experience, fairly

Design

Changing the Meaning: Breaking Semantic Changes

The subtlest kind of breaking change is the kind that doesn't affect a value's type but instead affects what that value means. These changes can be hard to notice when you're making them, and even harder to debug when they happen. They can lead

Design

Three Models of Value

In product development, we often think of "value" in large, discrete units: the value of project A vs project B; the value of a feature; the value of a refactor or architecture change. When we're deploying continuously, we have an opportunity to replace this mental model

Database

Constrain Your Data Access for Fun and Scale

ActiveRecord-style ORMs can be huge time-savers, but also blur boundaries within a system, which leads to bad assumptions and habits

data

Conceptual, Logical and Physical Data Models

Conceptual, logical, and physical data models has proven to be one of the most valuable things I've learned recently

Code

Building Extensibility into APIs from the Start

Making the right design decisions early in a project can have a huge impact on the ability to safely improve and evolve it over time.

testing

In defense of unit tests

A few years back, Guillermo Rauch—now the CEO of Vercel—tweeted a pithy assessment of automated testing: Write tests. Not too many. Mostly integration. — Guillermo Rauch (@rauchg) December 10, 2016 This inspired Kent C. Dodds to write that: Integration tests strike a great balance on the trade-offs between confidence

continuous deployment

Sliding Windows of Compatibility

Writing software professionally means constantly changing, evolving, and migrating applications. All-new "greenfield" projects are a rare treat, but not the norm. Constant change means we have to be comfortable making big changes applications that are running in production environments, usually with customers using them, and do it safely,

programming

Caller-controlled Rollouts

Slightly warm take warning: not everything needs to be feature-flagged. New APIs or API endpoints, for example, that have no callers yet, don't benefit from the ability to toggle them off. If nothing is executing this code, then there's no behavior to disable. Let's

zero

The Creative Power of Zero

Yesterday, I wrote about how a three-legged deploy process enables migrations in continuous deployment (CD). Today I want to talk about the creativity that hides in the gap between "a little" and "zero." One way to look for opportunities—I think attributable to Marty Cagan—to

continuous deployment

Zero Downtime and the Art of Continuous Deployment

I've been thinking a lot about the relationship between availability and continuous deployment (when I say "CD," I usually mean "deployment," all the way to production). One of the primary concerns people raise about CD is the perceived risk to availability or uptime. But

tech debt

Tech Debt, Depreciation, and Features

There was some discourse on Twitter (yes, it's still there, for now) yesterday about the nature of Technical Debt and how effective it is as a metaphor. The real seed was the new boss arguing with—and eventually firing—one of the few remaining engineers on the Android

human factors

Root Cause, Proximal Cause, or Least Effort to Remediate

I am no fan of "Root Cause Analysis." It's one of the many terms or concepts that software has borrowed from manufacturing—while ignoring the subsequent 70 years of research into human factors and resilience engineering. However, like Lorin, I admit that it has some value