Matthew Shaver's School for Developers Who Don't Code Good

A tactical field guide for engineers shipping software in high-security, high-stakes environments.

I've led teams shipping into IL6 and TS//SCI. The constraint set is real: air-gapped networks, policy gates, inherited monoliths, and zero margin for sloppy change control. The job is not to admire the complexity. The job is to deliver outcomes safely, fast.

Below is the playbook I've used with teams. It is opinionated on purpose.

1. The debugging decision matrix #

Pick the tool that gets you to high-confidence evidence with the least blast radius. Use this like a checklist before you touch code.

Situation	First move	You get signal if...	If not, escalate to	Stop and rewrite when...
Repro in prod only, impact contained, logs are noisy	Read logs with scoped correlation IDs; increase log level on the slice, not the service	You can tie errors to a single boundary (API, queue, DB)	Localized debug session in a hermetic replica with prod parity data shape	The fix requires cross-cutting changes to 2+ bounded contexts or breaks a shared contract
Repro in lower env, flaky tests, recent dependency bump	Pin versions and bisect the change set; run failing tests with trace	One commit window correlates with failure	Attach a debugger and single-step the narrowest suspect function	The root cause is a leaky abstraction you do not control and cannot sandbox
Performance regression with headroom gone	Capture a short CPU/mem profile and a single request trace	A single hot path dominates >40% of time	Debugger with perf counters on that hot path only	Data model or access pattern is fundamentally wrong for the workload
Security finding blocks release	Reproduce the finding locally with the same scanner and rules	The repro is deterministic	Step through the code that builds the artifact, not the app code	The supply chain is unpinned and unreproducible, or the policy cannot be satisfied without redesign

Rules of thumb: #

If a log statement would have prevented this, add it now. Not later.
If you cannot reproduce within 90 minutes, you are missing a boundary. Instrument, mock, or split until you can.
Never attach a debugger to prod. Recreate the conditions, not the environment.

2. Practical strategies for large monoliths in compliance-bound orgs #

You inherited a monolith. Fine. Treat it like critical infrastructure and evolve it with discipline.

Stabilize at the edges. Wrap external calls behind explicit interfaces. Lock API contracts. Add consumer-driven tests at every boundary so change control has evidence, not vibes.
Carve by seams, not by dreams. Split where the data or deployment seams already exist. Reporting, batch jobs, and adapters are usually first. If you need a strangler, start with read paths.
Pin and pave. Pin build and runtime toolchains. Pave a golden path for new features that starts outside the monolith whenever possible. Make it easier to add a service than to add another god-class.
Make the monolith boring. No new frameworks inside the core. Invest in observability and deployment reproducibility, not novelty.
Prove compliance continuously. Automate SBOMs, provenance, and policy checks in the pipeline so auditors see evidence attached to every artifact, not a once-a-quarter scramble.
Plan migrations like incident response. Small steps, reversible changes, an exit plan for every cutover. If rollback is folklore, you are not ready.

3. The day-to-day flow that keeps you fast and safe #

Short, sealed loops. Every change has the tests, tracing, and policy proofs to ship without a meeting. If a change needs a meeting, the loop is not sealed.
Radical reproducibility. Infra as code, environment as code, data shape as code. Same commit builds the same artifact everywhere.
Evidence over ceremony. Replace status docs with pipeline artifacts and dashboards that show readiness for release, not opinions.
Pre-mortems over post-mortems. Before changes, ask what breaks and how you will see it. Write the alert first.
Kill heroics. If a fix lives only in someone's head or local env, it does not exist.

4. When to rewrite #

Rewrites are last resorts. Do it when at least two are true:

The core abstraction is wrong and blocks policy compliance or basic scaling.
The cheapest safe change requires touching 3+ bounded contexts.
You cannot get to single-digit MTTR with instrumentation and tests.
Auditable supply chain is impossible without a new build path.

When you do rewrite, do it outside the blast radius: new module, new deployable, strangler on the read path first, then write.

5. Proof point from our world #

We built SmoothGlue to operationalize this discipline so teams can debug quickly and deploy safely in the hardest places. SmoothGlue provides a paved path to production built on top of Big Bang and aligned to DoD DevSecOps best practices, so teams get a production-ready platform with compliance and security controls baked in, not bolted on. That is why it is used across DoD initiatives at the highest impact levels and in mixed cloud, on-prem, and edge deployments.

The result for teams is straightforward: a code-low, deploy-high model where scaffolding, policy checks, and golden paths are pre-integrated, which shortens the distance from diagnosis to a secure update, even in IL-restricted environments.

6. A compact checklist you can print #

Can I reproduce in 90 minutes or less with the current boundaries and data shape?
Do I have logs, traces, and tests at the exact boundary that failed?
Is my change attached to an SBOM, provenance, and policy proofs in CI?
Can I roll forward or back without a meeting?
Did I make the next failure cheaper to diagnose than this one?

If the answer to any is no, fix that before you chase the next ticket.

7. Closing #

High-security, high-stakes software rewards teams that respect constraints and push flow to the edges. Read the system before you rewrite it. Prove the fix before you celebrate it. Ship boring, provable changes on a paved path. That is how you deliver outcomes when the mission cannot wait.