Engineering-Leadership on Brian Faust

Quality Needs a Risk and Capacity Budget

Wed, 01 Apr 2026 00:00:00 +0000

An API change took about eight hours to release and another sixty hours to repair properly after it kept causing trouble.

The API was an active legacy system already associated with recurring defects, service interruptions, unreliable tests, difficult tooling, and delivery estimates which could miss by a factor of four or five. We still added work in a known performance-sensitive area because a customer or partnership needed it now.

The commercial logic was not stupid. The company existed to sell, acquire customers, and make money. Everyone could see the immediate value. A failure six months away, conditional on traffic continuing to grow, looked more like an engineering opinion.

Choose a Stack from Constraints, Not Identity

Sun, 01 Mar 2026 00:00:00 +0000

We did not replace Laravel because Go was fashionable. We replaced it because CPU had become the limiting resource under concurrent inbound traffic, and the Laravel services had reached the point where more framework tuning no longer changed that fact.

After the migration, CPU use fell by almost 60 percent. The average endpoint became sixteen times faster while the services handled forty times as much traffic. We moved from machines with 16 CPU cores and 32 GB of memory to four cores and 16 GB. Infrastructure cost halved. Incidents fell.

A Decision Record Needs a Way Back

Sun, 01 Feb 2026 00:00:00 +0000

The incident review finds ADR-003: Use Redis for caching.

Redis is in the configuration. The record has successfully preserved the one fact the repository already reveals and lost everything the operator needs: what problem the cache solved, why the database was insufficient, which failure the team accepted, and when removing Redis would be safer than repairing it.

Making the document longer would not fix this. It could spend six pages describing Redis and still omit the choice, only making the missing reasoning harder to notice.

Boundaries Follow Work Without Becoming Destiny

Tue, 01 Oct 2024 00:00:00 +0000

We had a small team, so every service was officially owned by everyone. In practice, a developer could finish five hours of work in a specialist application and then spend three weeks integrating and testing it against the legacy API.

The delay was not a queue in front of another team. There was no other team. It came from a system which had evolved through changing commercial priorities, agencies, freelancers, and eventually an internal development team. Plenty of individual decisions made sense when they were made. Their combined cost still landed on the next person trying to change anything.