Working Notes

When people say “schema as interface,” they usually mean naming and semantics. That’s part of it. But in a production system, the real interface is the set of access paths the query planner can execute cheaply. Every `SELECT`, join, background job, and dashboard query depends not just on tables and columns, but on index shape, cardinality, constraints, and data distribution. The schema is not only a contract of meaning; it is a contract of performance. I’ve seen more systems struggle from schema drift than from application bugs. Not because the code was wrong, but because the data model made correct code slow. A table starts simple and well-indexed. Features accumulate. Nullable columns get added “just in case.” Enums become free text. Indexes are added reactively. At 50k rows, everything works. At 50 million, joins that used to be cheap become dominant costs. Nothing is technically broken—but the interface has changed. We would consider an API broken if latency jumped from 40ms to 4 s...

There’s a growing cottage industry on LinkedIn devoted to spotting AI-written content. People trade lists of tells—emojis, bullet points, excessive em dashes—as if the problem is detection. It isn’t. Those tells are just symptoms. The real issue is that a lot of what’s being published has no point of view, regardless of how it was produced. I came to this topic the same way many posts start: with an observation and a vague sense that something felt off. Using ChatGPT didn’t give me the idea. It helped me sharpen it. Through iteration, the problem became clearer—not that AI is writing content, but that it’s being used as a substitute for thinking. When that happens, the output is predictable: fluent, tidy, and empty. This failure mode isn’t new. Long before AI, we were already summarizing conference talks, management books, and other people’s blog posts. The same ideas get rephrased, lightly personalized, and pushed back into the feed. What’s usually missing isn’t information—it’s i...

When teams select a database, they're not just picking a storage layer—they're locking in product constraints for years. Database choices determine your application's latency characteristics, operational costs, and failure modes long before users ever see a feature. Yet these decisions often happen in technical silos, treated as implementation details rather than the product-shaping commitments they actually are. The most expensive databases aren't the ones with the highest licensing fees; they're the ones chosen without understanding how their fundamental tradeoffs will constrain what you can build and how quickly you can ship. The room where these decisions happen matters. When it's just backend engineers and DBAs, you get choices optimized for developer familiarity and operational comfort. That's not wrong, but it's incomplete. Product managers should be present because they understand user expectations around responsiveness and availability. Finance ...

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...