Blog

Christopher Alexander wrote about livable cities before the Gang of Four applied his thinking to software. The message was the same: good design solves problems people actually have, not problems that look interesting on a whiteboard. The Pattern Instinct Alexander’s 1977 book, A Pattern Language, revealed how timeless design principles create spaces where people thrive. The same thinking has made software systems more maintainable, more adaptable, and easier to reason about. Even if you don’t know the pattern names, you’ve almost certainly worked with them. ...

“Should we modernize the legacy system or build a new one?” I’ve watched this question consume months of debate. The instinct is to pick one path, commit, and move. But eighty years ago, a wartime memo made the opposite call … and it changed the course of history. Both Options In 1944, British codebreakers at Bletchley Park faced a problem: they needed to crack the Lorenz cipher faster than existing methods allowed. A GCHQ retrospective describes how a memo proposed two competing approaches. One was incremental. The other, Colossus, was called a “much more ambitious scheme” … the first digital computer. The recommendation was to pursue both. ...

Most database contention isn’t a database problem. It’s an application design problem that the database makes visible. If you haven’t already, start with the Prepare, Investigate, Report framework … it covers how to debug and report database issues before you get to the harder stuff here. Database contention is vexing because its roots are often in the application code, not the database itself. What Causes Contention The most common cause is application design that doesn’t account for how the database manages concurrency. When you hold locks for too long, the database is doing what you asked. Deadlocks are almost always an application design issue, and timeouts normally are too. ...

If your “database ticket” says “it’s slow” or “it timed out,” you’re not asking for help … you’re asking someone else to guess. I’ve watched good database engineers (DBAs) lose days to vague reports that are basically “something happened” with a request for help. Not because teams are careless, but because nobody taught them what DBAs actually need to investigate: the query, the error, the timing, and the context. DBAs want to be helpful. But their expertise is best used when developers can solve common issues independently and escalate the non-obvious ones with enough evidence to act. ...

This is a two-part series on how software engineers and database teams work together effectively. Good database collaboration starts with developers who can debug common issues independently and escalate the hard ones with enough evidence to act. When things get harder … deadlocks, timeouts, hidden triggers … the problem usually lives in your application code, not the database. Prepare, Investigate, Report - a framework for debugging database issues independently, reporting with evidence, and knowing when to escalate Database Contention Is an Application Problem - why deadlocks and timeouts usually trace back to application design: transactions, locks, frameworks, and triggers

What if an AI monitored whether you followed all rules and laws that applied to you … and then acted on what it found? Not flagged for review. Acted. Put you on a no-fly list. Accused you of fraud. No human involved. That scenario is the subject of Jon Penney’s guest post on Bruce Schneier’s blog, AI and Micro-directives. Penney focuses on the legal risks to the targets of AI-based decisions, but the legal exposure cuts both directions. ...

I once came back from a week off to find that a time-sensitive task had simply waited for me. Nobody dropped the ball … the ball was never passed. The team didn’t lack talent. They lacked the setup to succeed without me, and that was my fault. Your vacation is a stress test for your team’s resilience. If work piles up like garbage during a sanitation strike every time someone is out, the problem isn’t their absence … it’s that you didn’t give your team the tools they needed before a coworker left. ...