Breaking production on purpose
Chaos engineering has the most lurid name in software and the most conservative temperament. If recovery is a capability, this is how you find out whether you actually own one.
Chaos engineering has the most lurid name in software and the most conservative temperament. If recovery is a capability, this is how you find out whether you actually own one.
One DORA measures how fast you ship software. The other fines you for not proving you would survive a bad day. They keep turning up in the same meetings, answering to the same name.
Large language models are rarely the weakest part of a GenAI system. The prompts, permissions, tools and people wrapped around them usually are.
This site now answers questions over MCP through a tool called `ask_matt`. It quotes from published articles, hands over the hand-kept numbers when a question wants one, cites everything, and refuses the rest. The refusal took the most design effort.
Servers fail every day. Whether that becomes an outage depends far more on the organisation than the infrastructure.
Most engineering systems are built to answer what happened. The harder question, the one that surfaces at the worst possible moment, is who changed what, when, why, and whether they should have.
When every candidate has a world-class assistant in the next tab, the interview stops measuring memory and starts measuring judgement. Most processes haven't noticed yet.
HTTP is stateless, users are not. Most authentication systems are attempts to bridge that gap. The hard part is deciding which trade-offs you're willing to accept.
The danger of AI isn't that it makes engineers less productive. It's that it quietly removes the exercise that kept them sharp in the first place.
Lead time, deployment frequency and change failure rate tell us a great deal about delivery systems. They tell us surprisingly little about the performance of individual engineers.
Every technology generation promises to transform how software gets delivered. Most of them eventually rediscover that organisational structure shapes the outcome far more than the tools the engineers happen to be holding.
The most effective governance models don't rely on approval boards, process documents or compliance checklists. They make the right thing the easiest thing, and then mostly get out of the way.
Shared components promise consistency and speed. They also quietly centralise risk. What it takes to run a single UI platform across brands that genuinely want to look different.
The interesting question is no longer whether engineers use AI tools, but where they belong in the workflow and where they quietly make things worse.
Why Model Context Protocol matters less because of the protocol itself and more because it solves a problem every engineering organisation eventually encounters.
The hardest part of AI adoption isn't choosing tools. It's changing how engineers, leaders and organisations work around them.
Most software engineers think a payment is a database transaction. The payments industry has spent decades proving otherwise.
Most security incidents don't begin with sophisticated attackers. They begin with credentials sitting somewhere they shouldn't.
Code rarely becomes hard to maintain because engineers wanted it that way. More often the architecture is just a faithful record of the incentives, constraints and decisions of the organisation around it.
The problem isn't that engineering metrics are useless. The problem is that we often ask them to answer questions they were never designed to answer.
Most engineers think desktop platforms are about windows and toolbars. The hard parts are identity, communication, deployment, versioning and convincing hundreds of applications to coexist without setting fire to each other.
When a price moves, the screen has one job: show it before the trader notices the delay. A practical look at spending a latency budget across transport, processing, rendering and paint.
Most caching strategies look brilliant during architecture reviews and become considerably less impressive the first time stale data reaches production.
Occasional notes on platform engineering, building dependable software and that constant buzz word we doom scroll past on LinkedIn! No cadence promised.