Article
Against Shiny-Object Architecture
New tools deserve evaluation, not automatic adoption or automatic rejection.
Architecture, cognition, and practical judgment
Reflections on architecture, cognition, and complexity.
Welcome to my working notebook for building software that can survive change: skeptical of fashion, respectful of principles, and grounded in tools that serve humanity.
Field notes
Start Here
A short path through the center of the site.
Operating stance
Change is the default condition.
Good systems are not made by chasing every new surface area or flattening every disagreement into committee language. They are made by naming volatility, keeping options open where change is likely, and choosing proven mechanisms where behavior is already well-understood.
Field notes
Featured Writing
One entry that anchors the current direction of the site.
Field notes
Latest Writing
Concise notes on architecture, AI, complexity, and the work of staying intellectually honest.
Using Enumeration Generators
A lab note on using a source generator to turn a small enum specification into a richer enumeration type.
Why Use an Enumeration Class?
A lab note on replacing weak enum usage with richer named values that can carry identity, behavior, and safer conversion rules.
Coverage Did Not Fix the Design. It Exposed It.
A field note on using code coverage to reveal tangled responsibilities, hidden coupling, and the real cost of a big ball of mud.
Headcount Is Not Throughput
A field note on why adding another developer can slow a team down when the system and process cannot absorb more coordination.
Turning Around a Failing Team Is Mostly Removing Ambiguity
A field note on process improvements, communication, learning from mistakes, and building a culture of accountability.
Build for Change
Systems last longer when change is expected and visible instead of hidden behind optimism and wishful thinking.
Field notes
Active Series
Recurring threads without a heavy taxonomy.
Software
Projects as learning instruments.
LanStorm, DifferenceEngine, ConfigCompare, TaskSequencer, and cognition experiments show up here as examples of recurring design pressure: comparison, sequencing, feedback, inspection, and adaptation.
Coverage Did Not Fix the Design. It Exposed It.
A field note on using code coverage to reveal tangled responsibilities, hidden coupling, and the real cost of a big ball of mud.Headcount Is Not Throughput
A field note on why adding another developer can slow a team down when the system and process cannot absorb more coordination.Turning Around a Failing Team Is Mostly Removing Ambiguity
A field note on process improvements, communication, learning from mistakes, and building a culture of accountability.