Working Notes

Technical debt doesn’t accumulate by accident. In practice, it’s the predictable outcome of the choices we make about what gets done now versus what we consciously defer. When delivery pressure consistently outweighs investment in sustainability, teams respond exactly as designed. Technical debt as a deliberate trade-off: borrowing against the future to move faster today, with the expectation that the debt will be repaid later. The failure isn’t taking on debt; it’s pretending the loan doesn’t exist.  I didn’t fully appreciate this until I was accountable for backlog decisions myself. As a Product Owner, I regularly had to choose between delivering in the current sprint or taking the time to fully complete the design. Those decisions felt tactical in the moment — but they accumulated over time.  That’s why technical debt isn’t an engineering failure. In most organizations, engineers don’t own prioritization mechanisms, funding decisions, or success metrics. Those choices liv...

In the previous post, we argued that estimation is a smell—a signal that teams are compensating for unmanaged uncertainty. Velocity, as a direct descendant of estimation, inherits that smell. Scrum reminds us that the purpose of a Sprint is to produce an *Increment of value* , not to consume a predetermined number of points. Velocity measures effort expended inside the team. Customers, however, experience outcomes: features delivered, bugs fixed, and capabilities unlocked. No customer has ever benefited from a higher velocity. Why Velocity Persists Velocity survives because it is visible, numeric, and easy to chart. It gives leaders something to point at and teams something to optimize. Unfortunately, that optimization rarely aligns with value delivery. When a measure becomes a target, it ceases to be a good measure. When velocity becomes important, teams respond predictably. Estimates inflate. Stories are sliced to satisfy point targets rather than user needs. Lower-risk, lower-valu...

Part two in the Agile Engineering: Rhetoric vs Reality series. Agile teams frequently assert that they value outcomes over outputs, learning over prediction, and adaptability over rigid plans. Yet in practice, many teams devote a disproportionate amount of time and emotional energy to debating whether a piece of work is a 3 or an 8 . This tension reveals a persistent gap between Agile rhetoric and Agile reality. This post advances a simple claim: when estimation becomes a focal point of contention, it is a smell . Not because estimation itself is inherently flawed, but because prolonged debate over story points often signals avoidance of deeper issues—namely uncertainty, risk, and value delivery. Estimation and the Illusion of Precision Story points were originally introduced as a lightweight, relative mechanism to support short-term planning under uncertainty (Schwaber & Sutherland, 2020). They were never intended to function as precise measurements of effort or productivity. Howe...

Agile didn’t break engineering; it exposed where we quietly stopped doing it. Agile was designed to shorten feedback loops and surface risk early. But in many teams, it became a substitute for engineering discipline rather than a framework that depends on it. Ceremonies scaled easily—standups, sprints, retrospectives—while harder practices that require deliberate time and technical ownership slowly eroded. Infrastructure and database engineering are where this erosion shows up most clearly. Practices like  intentional schema design ,  explicit migration planning , and  backward-compatible data changes  often gave way to “we’ll fix it in a later sprint.” Database indexes are added reactively instead of modeled up front. Query performance is discovered in production rather than load-tested in staging. Stateful systems demand careful coordination and deep understanding, yet Agile workflows often assume everything is as malleable as stateless application code. The result...

 Software engineering moves quickly, but the problems teams struggle with tend to repeat. Every few years we adopt new tools, frameworks, or processes that promise speed and simplicity. Some deliver real value. Others quietly replace hard engineering work with ceremony, abstraction, or optimism. As we head into 2026, it feels like a good moment to pause and reflect on which practices have endured—and which ones we may have let slip. Over the coming weeks, I’ll be writing about a few recurring themes I’ve seen across teams and systems: how Agile practices interact with engineering discipline, why databases and infrastructure decisions shape products for years, and what it actually takes to run reliable systems in production. These posts won’t focus on tools or trends. They’ll focus on the unglamorous work—design, testing, operational awareness, and feedback loops—that quietly determine whether teams can move fast  and  safely. The goal isn’t to prescribe a single “right wa...

 I have the privilege of attending AWS Re:Invent conference from 02-Dec to 06-Dec. Here's my planned schedule for the week.  Sunday, 01-Dec Depart MSP @ 6:45pm CST Arrive LAS @ 8:12pm PST Monday, 02-Dec Design Secure and resilient relational database architectures on AWS Observability-driven development AWS Fundamentals for the accidental SQL Server database administrator Unleashing AWS Agility with Terraform How to navigate your SQL Server Migration journey with AWS Deep Dive into Amazon DynamoDB using Design Puzzles Visionaries in the Stadium w/ Angela Duckworth and some AI folks Tuesday, 03-Dec Identify and manage Amazon Aurora & RDS Snapshots Scalable database solutions with Aurora PostgreSQL Limitless Database Data models for Amazon Neptune using GenAI and diagram-as-code tools Deep Dive into Amazon Aurora query plan management Bingo Night Hashicorp Customer Reception @ Chica Wednesday, 04-Dec AWS Re:Invent 5k Race Essentials for migrating from Oracle to Amazon Aurora...