Logic Fault

On Reversibility

Wed, 14 Jan 2026 00:00:00 +0000

Reversibility is the most important quality of good software decisionmaking.

This is not a new idea.

Reversibility is more important than knowing “will this work at all?”. If you make a wrong decision but can reverse it, you’re fine. If you make decisions you can’t reverse and your strategy is “hope it’s the right call”, you’re building systems on the power of prayer.

What we talk about when we talk about reversibility #

Reversibility is not the same as the ability to iterate/improve on incomplete solutions. Iteration is well and good, but if you equate the ability to improve a system with the ability to go back to the way things were before you had that system, your outcomes will land somewhere between “endless struggles while continually wondering if this could have been done a different way” and “existentially annihilating hamster-wheel of layering forward-(not-quite-)fixes onto a cautionary monument to the sunk cost fallacy.”

Cute python trick: an @lru_cache containing bound methods

Thu, 24 Oct 2024 00:00:00 +0000

Here’s a cute Python trick I just discovered. I’m probably not the first one to find it.

Let’s say I want an @lru_cache that can contain bound methods.

I am not talking about a cache that decorates bound methods, like this:

class Leaky:
 @lru_cache
 def mymethod(self):
 return whatever

It’s (hopefully) well-known that this pattern can leak references to self. When people try to do this, what they usually want is a cache whose lifetime is bound to the lifetime of the instance in self. Such a cache exists: @cached_property or any one of its numerous backports or equivalents on PyPI.

On Data Lakes and Swamp Shacks

Thu, 20 Jun 2024 00:00:00 +0000

Your data lake probably looks like this and your data lakehouse will probably look like this.

Realism #

When building out data lake infrastructure, know the rate at which you currently need to access that data, as a ratio of “people who ask important questions that require icky and difficult queries/multi-data-source wrangling in order to answer” per unit time. Do not confuse that with the rate at which it would be super cool if you could access that data if you had a better data-{base,warehouse,lake,lakehouse,swamp,space-station}.

The Architecture of Annoyance: Diagnosing issues involving Cargo and DTrace on MacOS

Sun, 04 Feb 2024 00:00:00 +0000

This post is a lengthy narration of some debugging/resolution I did involving MacOS, dtrace, Rust, and cross-architecture binary execution. It has deliberately not been edited for brevity by removing red herrings (threads I pulled on that turned out to be unrelated), both because those other threads might be useful to some readers, and because I think it is important to explain your mistakes as well as your successes.

If you’re having a similar issue to the one discussed here and just want it fixed, jump to the tl;dr at the end.

Enterprise Software Terms: Syntactic Analysis

Fri, 23 Jun 2023 00:00:00 +0000

Ownership #

“If it has multiple owners, it has no owner” indicates a failure of accountability, not a failure in the ownership model.

Fortunately, failures of accountability are so common in software engineering that nobody needs to care about that distinction.

Monolith #

Nobody can agree on what a monolith is other than “a system where things break when we don’t want them to”.

Fortunately, fragile software is so common that anyone can accuse anything of being a monolith and be right, at least by that definition.

On Tools and Popularity

Thu, 23 Mar 2023 20:54:18 -0500

An overengineer once said:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

This is not quite right, or is at least incomplete. More accurately:

There are only two kinds of software tools: unpopular ones and misused ones.

A software tool will either be unpopular, or mis-used in 99% of cases.

Unpopularity is not so bad. Unpopularity does not mean “unused”. It means that nobody outside of the circle of people for which the tool was built uses it. That is okay. Not every tool needs to choose between “gets so popular that Dan Abramov obsoletes it with something overcomplicated and inferior”, and “checked into the ~~nice hospice by the park~~ Apache Software Foundation”. There is a third option: tools that serve a bounded community well and are content with that.

On Foresight

Tue, 07 Feb 2023 20:54:18 -0500

Things to do proactively in advance of anticipated need:

Pee
Save money
Be kind

Things not to do proactively in advance of anticipated need:

Stockpile nuclear weapons
Purchase cryptocurrency
Extract code into a microservice

On Cloud Runtimes

Thu, 02 Feb 2023 13:28:21 -0500

So. You are in a hurry and want to ~~compromise your users’ data~~ publish an app in a hurry.

Your head’s on straight: you don’t want to worry about the hard parts; you definitely don’t want to worry about scale/best-practices until you feel a pulse. You’re a beginner–either to software engineering in general or to standing something up _from scratch_(1) (1)That second demographic is huge (personal projects + first-time startup founders + disposition:kleenex line-of-business apps for simple things): given the number and size of huge software orgs, most people doing development have passed through one at some point in their lives. Like waste through a bowel. Anyway. . You don’t want to go back to heroku, you don’t want to go deep, and you don’t want to go wide.

On Interns

Wed, 25 Jan 2023 00:00:00 +0000

A hypothetical intern or very junior/first-time programmer comes up a lot in discussion of design patterns. “Sure,” pattern advocates say. “Deciding what to do on a case-by-case basis informed by pragmatism and experience is swell, but what about someone who is too early in their career to have either of those things? We need to ~~give the masses opiates~~ come up with a set of hard-and-fast rules people can follow without understanding them first, to get them productive quickly. They can grow into the subjective/squishy decisionmaking later”.

On Maintainers

Sun, 22 Jan 2023 00:00:00 +0000

Code is read more than it is written.

Code is read by low context people in high urgency situations more than it is read by anyone else.

If your design patterns impose multiple “hops” in the call stack chain to a given business operation A invoked from another place B, a user who wants to modify/add to the set of side effects of A is more likely to make the change in the wrong place (e.g. in B, or in an intermediate/abstract-lookup-point location, rather than in or near A itself).

Abject Rancor

Fri, 20 Jan 2023 00:00:00 +0000

Writing the most valuable code for your team and customers is a lot less fun than most people think it is. So we find ways to make it more fun. The human brain really likes doing this and hates doing this, so one of the ways we make coding more fun is devising ways to give ourselves an “I’m objectively correct” dopamine hit, or a “I made everything uniform and uniformity pleases lizard brainstem that doesn’t like rough scales that need to be shed” when we check in a change.

On YAGNI

Fri, 20 Jan 2023 00:00:00 +0000

Let’s talk about modularity/swappability, sometimes called “abstraction” (v.). This is the practice of writing the ability to “change one part without touching other parts” into your codebase. This is sometimes equated this with the “L” or “D” in SOLID, but the practice extends farther than that.

Examples include:

Let’s make all of our data access SQL-engine agnostic so we can switch from MySQL to Postgres if we want

…and:

Let’s introduce two abstract interfaces, a DTO, and two repository classes so we can transfer a single string from one table on one database to another, just in case we someday develop a need for a GeneralPurposeDatabaseOneToDatabaseTwoStringTransferenceEngine.

On Feelings

Tue, 17 Jan 2023 00:00:00 +0000

Many teams who “successfully” apply design patterns to a codebase feel that they were successful because changes are now much easier for them to make. Consider that this may be because of the patterns used, or it may simply be because the introduction of patterns caused the engineers to touch, rework, develop muscle memory of, and otherwise get familiar with the whole codebase. The latter is far more likely.

“Teams” means “you” here. Individually, you feel good about the state of code if you understand how it’s structured when you debug it or make changes. Ask yourself where the emphasis lies: is the main benefit that you understand how it’s structured (as in: it’s structured in a way that objectively makes it easier to work with)? Or is the main benefit that you understand how it’s structured (that is: you are familiar with it and have a good mental map)?

On Subclassing

Mon, 16 Jan 2023 00:00:00 +0000

Class hierarchy is inferior to if/else as a way of modelling conditional behaviour. This statement probably doesn’t mean what you want it to mean, though.

Prefer shorter hierarchies with functionality-containing abstract classes over interfaces.

It is better to add a small amount of functionality to the “wrong” class in a hierarchy (i.e. adding specific functionality to an abstract base class, or adding functionality that conditionally detects situations that only arise in sibling classes to a leaf class) than it is to add an entire new layer to the hierarchy. This is only occasionally a mutually exclusive choice.

On Tests

Sun, 15 Jan 2023 00:00:00 +0000

If you have to choose between tortured, hard-to-read production code and tortured, hard-to-read tests for that code, it is better to have bad tests than bad prod code. This is rarely a mutually exclusive choice.

That is not a contentious claim, but the corollary is: if you have to choose between no tests at all and tortured, hard-to-read production code, it is often better to have no tests.

Perfer mocking as a means of changing behaviour in tests. If your language doesn’t have good support for mocking and a strong community/set of norms around that process, I’m sorry for you.

On Code Organization

Fri, 13 Jan 2023 00:00:00 +0000

It is easier to feel good about reading SOLID-factored code, but it is easier to read and understand under-abstracted code quickly.

Default to putting related code as close together as possible. The more lines of indirection you add to service2.insert(service1.select(...)) the harder it is for people to maintain the code.

If primitive data (say a string of “customer ID”) is what’s present at the top of the call stack and that primitive data is the only thing needed to perform business side effects at the bottom of the call stack, do not convert that data into a more complex business object. E.g. if a “customer ID” string is available at the top, and it can be used to build a multifield “customer” object, but only the “ID” field of said object is used in a “select-from-where-customer-ID-equals” at the bottom of the stack, don’t hydrate the ID into a full Customer object. Hydration often involves I/O and extra computation, and obscures the actual behaviour of downstream code: in this regard, the presence of the ID in the top-level call signatures indicates to readers that only locator keys are needed by the code below. That’s a strong hint about the IO interactions and behaviour of the function in question, if you’re reading in a hurry.(1) (1)Most people are.

On Mutual Exclusivity

Thu, 12 Jan 2023 00:00:00 +0000

Lots of the things on this blog talk in terms of “it is better to do good-thing-X than good-thing-Y”. Just like there’s an implicit “too” after “Black Lives Matter”, there’s an implicit “if X and Y are in conflict” after these statements. Often, they aren’t in conflict. In many cases, in fact, good prior engineering practices should have brought about an environment in which X and Y is easier to achieve than either X or Y alone. However, sometimes that ain’t what we got, and that’s where the advice in these posts applies.

On Reactivity and Need

Wed, 11 Jan 2023 00:00:00 +0000

Refactoring/Abstracting Code Reactively #

A lot of the content under “design patterns” here has a punchline of “do so-and-so-practice reactively”. That’s a surprisingly nuanced statement to unpack, even without knowing what the practice is. It turns into something like:

“I know it’s painful to suddenly context switch into unpredictable-duration refactoring in the middle of cranking out features, and I know it sucks when deadlines slip, but if you don’t build yourself a culture where you can do that, you can’t get the benefits of that refactoring in any other way, and you certainly can’t achieve them by doing the refactoring up front”.

About

Sat, 01 Jan 2000 00:00:00 +0000

What is this place? #

This is one of Zac Bentley’s websites. Zac (he/him) thinks programming is pretty neat. Programmers are another story.

Contact #

I can also be found elsewhere:

For direct outreach, message me on LinkedIn. If you ignore that recommendation and try to reach me some other way, the bar for “why shouldn’t I block/mark-as-junk you” will be high.