A postmortem is easy to hold and hard to make useful. The meeting happens, a document is written, four action items are recorded, and six months later the same failure occurs and somebody finds the old document while searching for something else. The word “blameless” gets most of the attention in discussions of this,...
Code Quality
Articles, guides and tutorials on code quality, covering review practices, static analysis, testing and maintaining clean, maintainable codebases.
Technical documentation fails in a specific and predictable way. Somebody writes a great deal of it during a quiet fortnight, the system changes, nobody updates it, and within a year the document is confidently wrong. At that point it is worse than nothing, because a reader who trusts it acts on information that no...
Developer onboarding is usually measured in how long the induction takes, which is the wrong end of the problem. The number that matters is how long before a new engineer can change something and be confident they have not broken anything else, and in most teams that is measured in months rather than days. The delay is...
API versioning arguments usually start at the wrong end, with where the version number goes. That is the least consequential decision in the whole subject. What matters is which changes require a new version at all, and most teams get that wrong in the direction of complacency: they ship something they believe is...
Technical due diligence is not a code quality competition, and teams preparing for one usually spend their time on the wrong thing. Nobody buying a company is grading your abstractions. They are trying to work out what it will cost to own this system, and how badly it can go wrong after the money changes hands. That...
Database performance work usually begins with someone proposing a bigger instance, and it usually ends with the discovery that one query was doing a sequential scan over four million rows on every page load. The hardware was never the constraint. The plan was. That pattern is consistent enough to be worth stating as a...
Software testing strategies are usually described in terms of coverage, and coverage is the least informative number in the whole discipline. A codebase at ninety per cent can ship a bug on its most-used path, because coverage measures which lines executed during a test run, not whether anything meaningful was asserted...
The software development life cycle, usually shortened to SDLC, is the structured process teams follow to take software from an idea to a working, maintained product. Understanding it matters whether you build software or commission it, because the quality of the process largely determines the quality, cost, and...
Web development best practices are the difference between a website that merely works and one that performs, ranks, and lasts. In 2026 the bar is higher than ever: users expect instant load times, search engines reward speed and accessibility, and security threats are relentless. The good news is that the practices...
Searches for “technical debt” have grown by over 35% in the past two years, driven in large part by UK engineering teams inheriting legacy systems built under deadline pressure and now struggling to maintain or extend them. The term gets used loosely in Jira backlogs and sprint retrospectives, but most developers have...