… a nerd with an MBA
I explore how foundational CS principles translate to business outcomes. Expect notes like: why Conway’s Law matters for quarterly planning, how interface design affects coordination costs, why being in a constant reorg actually makes sense (never thought I would write that one), or what “production ready” really means at 2am.
(Staff engineer. Multiple engineering disciplines inside and outside the tech industry. MBA. I write for people who need to connect code to business outcomes.)
Areas/Folders
- Strategic software architecture, organizational design
- AI for thinking developers
- Technical debt as business risk
- Platform engineering and developer productivity
- AI/ML system architecture
Latest pages
Go Interfaces: Thoughts on Composition Over Inheritance – Mar 2026 Who should own the contract—the producer or the consumer? Consumer-defined vs producer-defined interfaces, and why the right answer depends on the ownership boundary
Serviceability Checklist for Startup Microservices – Mar 2026
Application-level readiness patterns that reduce MTTR and change failure rate—a soft checklist for production readiness from startup health checks to observability
Service-Oriented Architecture, Platform Building, and Yegge’s Rant – Mar 2026
A practical reading of Yegge’s platform mandate—why hardened interfaces are an organizational strategy for scaling velocity, lowering coordination cost, and reducing maintenance drag
How Do Committees Invent? – Feb 2026
Conway’s Law and the rational case for perpetual reorganization—why your system architecture looks like your org chart, and why that matters for business outcomes
An example of encapsulation in Go: Enums for Status Disclosure – Feb 2026
Applying information hiding principles to API design—how status enums reduce coordination costs and enable parallel team development
MCP vs Terminal Calls – Feb 2026
Context, composability, and design tradeoffs for AI tool calls—why CLIs are more flexible and context-friendly than MCPs, and practical advice for tool builders and developers.
On the Criteria to be Used in Decomposing Systems into Modules
How Parnas’s 1971 insights remain essential for modern software architecture and business strategy
The Structure of the “THE”-Multiprogramming System
Layered abstractions as a system design and verification strategy