Tag: Engineering

The research-backed case for measuring software delivery performance through deployment frequency, lead time, change failure rate, and mean time to recovery.

A pattern where a stream-aligned team owns both its frontend and a use-case-specific backend, decoupling from shared platforms.

The C4 model organizes software architecture diagrams by nested levels of detail.

Consumer-driven contracts that replace coordination meetings between teams with automated integration guarantees.

Technical debt is swallowing the roadmap and every refactor feels like a fight.

An outcome-first model for selecting and validating metrics that gauge progress toward desired results.

Why documentation should be validated the moment code changes, not after the fact.

Four key metrics for measuring software delivery performance: lead time, deployment frequency, change failure rate, and mean time to recovery.

Examining whether AI coding tools enhance or erode the engineering craft.

Restructuring development processes to reduce coordination complexity and modernize a legacy codebase.

A playbook for balancing product delivery with system quality through deliberate technical investment.

Opinionated but optional platform defaults that make the right thing the easy thing for stream-aligned teams.

When a measure becomes a target, it ceases to be a good measure.

Stream-aligned teams temporarily contribute to platform code when they need a capability, without creating a permanent dependency.

Keep The Lights On and Business As Usual work -- what it is, how much is healthy, and what to do when the ratio gets out of control.

Two developers working at one machine, producing higher-quality code through continuous review and shared context.

Make an economic case for pursuing a process improvement or driving down toil using back of the envelope math.

Simon Brown's practical guide to thinking about, drawing, and communicating software architecture, where the C4 model originated.

Three strategies for more productive engineering collaboration when tackling technical debt.

Martin Fowler's article introducing the four quadrants of technical debt (deliberate/inadvertent vs. reckless/prudent).

Martin Fowler's two-by-two matrix classifying technical debt by intent (deliberate vs. inadvertent) and discipline (reckless vs. prudent).

A hands-on workshop that teaches engineering teams to reframe technical debt as strategic investment, build economic cases for paying it down, and manage a portfolio of incremental technical improvements.

Ward Cunningham's 1992 OOPSLA paper that introduced the technical debt metaphor.

A playbook for shifting from metrics-first to outcome-first measurement in engineering teams.

The hidden cost of AI-assisted coding when developers trade deep learning for short-term productivity.