Complex JVM systems rarely become painful because “dependency injection exists.” They become painful because dependency wiring becomes invisible, magical, or scattered everywhere. Services instantiate repositories directly. Routes know too much. Tests need half the application running. A simple change in billing, pricing, or customer policy triggers a chain reaction through controllers, adapters, and infrastructure code. […]
Most teams ask, “When do you want it?” and then reverse-engineer hope. That is how commitments become roulette. The passage from This Is Lean reminds us that customer demand must be decomposed operationally: what we need, when we need it, and how much we need to deliver on time. In software, this means understanding dependencies, […]
Complex JVM applications rarely fail because of the “happy path” we remembered to test. They fail in the weird combinations: empty lists, duplicated IDs, invalid ranges, timezone edges, rounding errors, unexpected Unicode, concurrent retries, and business rules colliding in ways no one wrote in a Jira ticket. Traditional example-based tests are useful, but they depend […]
If you’re a Staff Engineer parachuted into a degraded ecosystem with years of “quick fixes,” systems that don’t talk, recurring incidents, flaky pipelines. The instinct is to propose a big rewrite or a “new architecture initiative.” That’s structural change in disguise: it threatens ownership, timelines, and identity (“my service,” “my module”), and it triggers the technical version […]
We don’t lose delivery speed because we write too little code, we lose it because we keep too much. Accidental complexity creeps in as “temporary” feature flags that never die, defensive abstractions “just in case,” and frameworks wrapped in even thicker frameworks. The result: slower reviews, brittle tests, zombie endpoints, and a cognitive tax that […]
We don’t miss deadlines because we’re lazy; we miss them because we try to ship boulders. The fastest way to unjam a roadmap is to make “normal work” smaller, so small it fits through your delivery system without special favors, heroics, or weekend fire drills. When you slice initiatives into digestible chunks that finish in […]
We ship lots of code that “works,” yet every release feels like walking on eggshells. Open your repo: the top folder screams Rails or Spring/Hibernate, not Claims, Billing, or Inventory. Tests boot web servers, controllers know too much, and a minor library upgrade ripples through half the system. This is the real problem: we’ve let […]
Top-down architecture memos and “do this because I said so” design reviews feel efficient, but they create the worst kind of drag: invisible waste. Context lives in a few heads, juniors stall while waiting for approvals, and the codebase grows ceremoniously rather than with clarity. Hand-offs multiply, PRs age, and complexity sneaks in as people […]
We’re great at shipping output, closing tickets, burning story points, and merging branches. But output isn’t the problem; waste is. Features nobody uses, “just-in-case” abstractions, month-long branches, and handoffs that turn days into weeks all inflate lead time without creating customer outcomes. Maintenance is growing faster than roadmap work, reliability is drifting, and the team […]
Long-lived feature branches feel safe, but they silently tank flow: stale code, surprise conflicts, runaway rebase sessions, and lead times no stakeholder can predict. That’s the problem Mark Seemann’s advice exposes: big batches create significant pain. When integration is a “phase,” delivery becomes episodic, risky, and political. Work piles up, feedback arrives late, and teams […]