Managing Essential Complexity: An Engineering Practice.md

I have built and maintained systems for the California State Legislature for over a decade. The pace of this work is faster than most assume, and the stakes are public record. The principles below were forged in that environment. They are not theoretical best practices. They are the result of maintaining mission-critical applications and learning from the friction that only surfaces years after a system goes live.

Live with what you ship

I still maintain systems I architected at the beginning of my career. In an organization where applications evolve over decades, that continuity teaches you lessons that reading about maintainability never could. You discover exactly which abstractions held up under real-world pressure and which became obstacles everyone works around.

That experience compounds. I build every system with a strict assumption: anyone on the team must be able to maintain it five years from today. Sustainability is a shared responsibility. The best way to future-proof an architecture is ensuring no single engineer has to carry it alone.

Solve the problems that need you

I have worked with Drupal my entire career. It provides authentication, role-based access control, and session management out of the box. These are solved problems, and I treat them that way. I lean on foundational frameworks so I can spend my engineering hours where they actually matter: the complex domain logic that requires institutional knowledge to execute correctly.

Engineering for the legislative process requires understanding the lifecycle of a bill, the urgency of floor sessions, and the mechanics of multi-department workflows. The most valuable technical decisions I make come from knowing exactly which problems deserve my time and having the discipline to outsource the rest.

Manage essential complexity

The systems supporting legislative operations carry heavy institutional complexity. This is essential complexity. It lives in the problem domain and cannot be designed away. It can only be managed well or managed poorly.

The part I control is the accidental complexity. I actively prevent the codebase from accumulating unnecessary abstraction layers or clever patterns that obscure intent. Clever code is a liability. A new developer should be able to trace a request through the system without a guided tour. I aim for architectures robust enough to handle the institutional weight, but clear enough that the next person can work in them confidently.

Verify what you ship

A system is only as trustworthy as the automated checks gating its release. For the AI features I build, this requires a rigorous evaluation harness. Representative queries live in fixture suites, including explicit attempts to break the system through prompt injection or scope extraction. A failure stops the release rather than generating a ticket.

The rule is simple: every correct refusal becomes a permanent fixture. When the system declines a prompt it should have declined, that exact shape goes into the suite so a future update cannot silently undo it. When it fails to decline, we treat it as a defect with a root cause, not a prompt engineering issue. Under fixed legislative deadlines, I do not always write the test first. But I absolutely demand a definition of “correct” and an automated way to verify it before shipping.

Engineer for accountability

When a production system breaks during a legislative session, recovery depends entirely on whether the system can be questioned. This requires structured logs that tell a coherent story, error paths that surface detail instead of swallowing it, and decisions encoded clearly enough for a reader to follow without insider knowledge. Auditability and traceability are non-negotiable properties of mature production engineering.

A system that someone else can maintain five years from now is the exact same system you can debug under pressure today. Both rely on a codebase designed deliberately for the people who will inherit it.