The architecture decisions that age well
Some choices are cheap to change later and some quietly harden into constraints. Knowing which is which is most of the job.
Read postBLOG
Notes from the build.
Practical writing about the decisions that shape software projects — including the ones that are easy to get wrong.
01 / LATEST
Recent posts.
Why clarity outperforms visual complexity in enterprise software
The interfaces people rely on all day are judged by a different standard from the ones they visit once. That standard is legibility under fatigue.
Read post
Modernising a legacy system without betting the business on a rewrite
Full rewrites fail at a rate that should worry anyone proposing one. The alternative is slower to start and far more likely to finish.
Read post
What a cloud migration actually costs
The infrastructure bill is the part everyone models. It is rarely the part that causes the overrun.
Read post
Shipping regularly is a quality strategy, not a speed one
Teams that release often are usually accused of moving fast. In practice they are the ones taking the smallest risks.
Read postAn estimate is a forecast, not a promise
Software estimates are treated as commitments the moment they are written down. Here is how to keep them useful without pretending to a precision nobody has.
Read postTechnical debt is a decision, not an accident
Debt taken deliberately to hit a date is a strategy. Debt accumulated because nobody was looking is a different thing entirely, and the two need different responses.
Read postWhy migrations take longer than anyone plans for
The migration itself is rarely the hard part. What takes the time is discovering everything the old system was quietly doing that nobody documented.
Read postAccessibility is not a compliance task
Teams that build accessible interfaces tend to build better ones generally. The correlation is not a coincidence, and it explains why bolting it on afterwards never works.
Read postYour monolith is probably not the problem
Microservices are frequently proposed as a cure for symptoms they do not treat. A look at what actually causes slow delivery, and when splitting genuinely helps.
Read postWhat a slow test suite actually costs you
A forty-minute test run does not cost forty minutes. It changes how often people run tests, how large their changes get, and how quickly they find mistakes.
Read postDesign the error case first
Most interfaces are designed around the path where everything works. Users spend a surprising amount of their time on the other paths, which are usually an afterthought.
Read postWhen not to use machine learning
Some problems have a correct answer that can simply be computed. Reaching for a model there adds uncertainty, cost, and an explanation problem you did not need.
Read postDocumentation that survives contact with a codebase
Most documentation is wrong within months because it describes things that change. The parts worth writing are the parts that do not.
Read postPerformance is a feature, and it is usually a cheap one
Speed is treated as an optimisation to schedule later. It behaves far more like a feature: it changes what users do, and it is easiest to build in early.
Read postHow to evaluate software you are not qualified to judge
Buyers are routinely asked to choose between systems they cannot assess technically. There are still reliable signals, and most of them are not about features.
Read postWhy adding people slows delivery down
Communication overhead grows faster than capacity does. Understanding the shape of that curve explains a lot of otherwise baffling project outcomes.
Read postLogs, metrics, and traces: what each is actually for
Three tools, three different questions. Teams that conflate them end up paying for all three and answering none of them well.
Read postRequirements will change, so stop pretending otherwise
Change is treated as a failure of analysis. It is usually the correct response to learning something, and the plan should be built to absorb it.
Read postThe security basics outperform most security products
Breaches rarely involve novel techniques. They involve credentials, unpatched software, and permissions nobody reviewed — none of which a new tool fixes.
Read postBad reporting is almost never a dashboard problem
When two teams arrive with different numbers, the tool is usually blameless. The disagreement is upstream, in definitions nobody wrote down.
Read postWhat happens in the first ninety days after launch
Launch is treated as the finish line, so the period where a system is most fragile is also the period with the least planned support.
Read postTreat your API as a product, because someone depends on it
Internal APIs get designed as implementation details and then acquire consumers who cannot be broken. The habits that prevent that are cheap if adopted early.
Read postWhy rewrites fail, and what to do instead
The second system is meant to fix everything wrong with the first. It usually arrives late, missing behaviour the old one had, and with new problems of its own.
Read postThe case for boring technology
Every unusual technology choice spends a limited budget. Spending it where it does not create advantage leaves nothing for where it would.
Read postWhat a discovery phase should actually produce
Discovery often ends with a deck and a warm feeling. It should end with artefacts that change what gets built and what it is expected to cost.
Read postIntegration is where projects quietly slip
Each component is finished on time. Then they have to talk to each other, and weeks disappear into problems nobody assigned to anyone.
Read postThe alert nobody reads is worse than no alert
Alerting systems fail quietly. They keep firing, people keep dismissing them, and everyone assumes the system is being watched.
Read postMobile first is not a layout decision
Treating mobile as the desktop design rearranged misses the point. The constraint that matters is attention, not width.
Read postEvery configuration option is a permanent liability
Settings feel free to add and are almost impossible to remove. Each one multiplies the number of states your software can be in.
Read postCode review works best when it is not quality control
Review used as a defect-detection gate is slow and not very effective. Used to spread knowledge and question approach, it is neither.
Read postWhy nobody opens your dashboard
Dashboards get commissioned, built, demonstrated, and abandoned. The pattern is consistent enough to be avoidable.
Read postDesigning an on-call rotation people can sustain
On-call burns people out when the load is invisible and the alerts are noisy. Both are fixable, and fixing them improves reliability too.
Read postA prototype answers a question and then dies
Prototypes that become production systems carry every shortcut taken while learning. The value was in the question, not the code.
Read postInternationalisation is not a translation problem
Swapping the strings is the easy part. Dates, names, addresses, sorting, and text length break far more often, and they break silently.
Read postMost recurring meetings are unmade decisions
A meeting that recurs indefinitely without producing decisions is usually compensating for something structural that nobody has fixed.
Read postFeature flags are debt with a useful purpose
Flags decouple deployment from release, which is genuinely valuable. Left in place, they multiply code paths nobody is testing.
Read postNaming is design work, not decoration
A name that is slightly wrong quietly misleads every person who reads it afterwards, and the cost compounds across a codebase.
Read postA backlog of eight hundred items is not a plan
Backlogs grow because closing an item feels like a decision and leaving it feels free. The accumulation has a real cost.
Read postCaching is a correctness decision, not a performance trick
A cache is a deliberate agreement to serve data that may be wrong. Deciding how wrong, and for how long, is the whole design.
Read postEverything is green and users are complaining
Monitoring built around infrastructure health reports success while the product is unusable. What to measure instead.
Read postConsistency beats cleverness in interface design
A novel interaction has to be learned. A familiar one is understood instantly, and users did not come to admire your originality.
Read postVendor lock-in is a spectrum, not a binary
Avoiding every proprietary service costs real capability. The useful question is what each dependency would cost to unwind.
Read postHave a complex technology challenge?
Start a conversation Bring us the problem.
Share the goal, the challenge, or the idea. We will help turn it into a clear digital path.