Focus on Finishing, Not Starting

It’s important to focus on delivering value quickly rather than starting something early. The last thing customers and managers expect is that it’s common for software building teams to unintentionally create artificial delays. Yet teams do this all the time by trying to build every feature at once. Half‑done or half‑tested features pile up and prevent deployment. Instead it’s better to prioritize the most important features first and finish them end‑to‑end. Deliver vertical slices and only call it “done” when an the code, the tests, and the docs are finalized. And consider using feature toggles when you must decouple rollout from completion. ...

2025 February 24

We Will Not Ship Crap: The Builder's Promise

As a team we should expect one simple thing from our work: We will not ship crap Managers, customers, and users reasonably expect high-quality systems with few defects. When we slack on quality, we betray that trust. The team must push practices that stop bad code: testing, refactoring, simple design, and continuous customer feedback. These are not ceremonies — they’re tools that make quality repeatable. Builders should treat them as nonnegotiable habits, not optional extras. Doing so keeps our work dependable and our reputation intact. ...

2025 February 21

Thirty Computers in the Room

Look around now - how many computers are in the room? I count about thirty. Phones, the TV, my dyson heater, my headset, my oura ring, remote controls : nearly everything with a button on it runs software. That matters because every one of those devices needs code written by teams likes yours. Software touches law, health, transport, and food systems. And small mistakes can cascade into real harm. As software builders, we must treat our craft as responsible work: design carefully, test relentlessly, and assume our code has consequences beyond the screen. ...

2025 February 20

Upping Our Game: Professionalism

Agile development prizes discipline over ceremony. It’s a promise to raise our craft and to foster professional behavior across all aspects of software development. I’ve seen teams ship junk, and just casually accept defects, and make poor lazy trade-offs. It’s surprising to see some of those habits being tolerated at some organizations. If we want respect for our work, quality and discipline must be nonnegotiable. Discussions for your team Are we being professional and constantly finding opportunities to pair, clean out tech debt, and refactor? Do our cycles produce quality (almost) bug free output each time? What practices are we following to prevent unsafe or low-quality releases? How are we guiding our team to continually improve our level of professionalism?

2025 February 19

Extreme Programming

Of all the agile processes, Extreme Programming (XP) is the clearest, most complete, and least muddled. Many other software developerment approaches that were invented afterwards are a subset of - or a variation on XP. I don’t dismiss those approaches; some fit specific projects types. But when I want my builders to learn what the original agile software development approach was about, I point them to XP as a great template to start with. ...

2025 February 18