Posts

We’re in this team to make changes. It’s not a nuisance - it’s the job. Our careers and our value come from making change cheap and safe. That means designing for adaptability, writing tests that protect refactors, keeping designs simple, and automating where we can. We celebrate change by making it routine: small batches, continuous refactoring, and visible tests so every builder can evolve the system without fear. When we make change inexpensive, the business gets faster feedback, customers get better products, and builders do the work we were hired to do. ...

Software exists to be changed. “Ware” means product; “soft” means easy to change. If our systems are hard to alter, we’ve turned software into hardware by mistake. When requirements shift and builders complain, “That change breaks our architecture,” it’s a clear indication that the architecture sucks! Embrace change as the point of the work. We make change inexpensive by focusing on tests, refactoring, simple design, and pairing. And we build architectures that bend without snapping so the team can deliver value continuously instead of fighting the codebase. ...

Your codebase is one of the team’s primary teachers. New people don’t learn from manuals, they learn by reading the existing code and copying its habits. If the code is messy, newcomers adopt those same messy habits. And adding heads only multiplies the problem: more people results in more copies of the same bad patterns, and so productivity keeps sliding. I’ve seen managers repeat the same fix — hire more — and expect different results. But that rarely works. The real solution is to change what the code teaches: make it readability, testable, and make refactoring a norm. ...

We want steady velocity, not wild swings. Have you noticed how early in our projects we fly; but later, code messes pile up. That mess creates back pressure - the bigger the mess, the slower our team goes. And then our slow team faces even more schedule pressure, which encourages quick hacks that make the mess worse. That feedback loop can grind the team toward immobility. The “fix” is often, to add more people, but the new hires learn from the existing messy code base, and they often take on the same behaviors that produced it. ...

Some teams create a “stabilization” window after a sprint because features are half done, half tested, or half documented. This delivery delay frustrates customers. A better approach is to have systems in place that enables our software to always be technically deployable at the end of every iteration. From the builders’ point of view that means code is clean, tests pass, documentation up to date, and the implemented stories are stabilized. ...