Tag: Engineering

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

A six-week diagnostic scored a multi-brand e-commerce group at 75 against a top-decile benchmark of 82, then priced the seven-point gap at just over $1,000,000 a year.

Margaret-Anne Storey's triple debt model and why AI accelerates the two invisible layers, cognitive debt and intent debt.

The lived experience of shipping code in your organization, reduced to three measurable dimensions: feedback loops, cognitive load, and flow state.

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

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

DX's unified framework folds DORA, SPACE, and DevEx into four counterbalanced dimensions. Here is what it measures well and where it misleads.

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

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.

Ward Cunningham's original metaphor explaining why shipping imperfect code can be a rational economic decision.

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

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

Engineering spend keeps climbing, your engineers say everything is friction, and nobody can prove where the friction actually is.

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

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

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

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

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.

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

The paper that reduced developer experience to three measurable dimensions: feedback loops, cognitive load, and flow state.

Margaret-Anne Storey's article proposing a triple debt model of technical, cognitive, and intent debt for reasoning about software health in the age of AI.

DX's unified measurement framework, folding DORA, SPACE, and DevEx into four counterbalanced dimensions.

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

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

The paper that killed the single-metric view of developer productivity and replaced it with five dimensions you curate from.

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

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.

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

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

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.

A 4-6 week discovery program that measures developer experience across your engineering organization, then turns the findings into a prioritized improvement plan.

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.