Posts

Our software should improve with time. Painters refine paintings and homeowners improve houses - our software should get better, not worse, as we work on it. Continuous improvement means the architecture, code, and performance progressively mature. If we accept creeping cruft and brittle designs, we betray our users and stakeholders. Instead, let’s make daily habits of pairing, TDD, refactoring, and simple design. These practices let help us to steadily reduce technical debt, increase throughput, and make the system safer to change. ...

If the software is hard to change, we’ve defeated its purpose. Customers, users, and managers rightly expect that changes are straightforward and proportionate in cost. When change becomes costly, trust and velocity evaporate. The fix is practical, not mystical. Make change cheap by practicing TDD, continuous refactoring, and simple design. Tests give us safety to refactor. Refactoring keeps the codebase healthy. Simple design prevents unnecessary coupling. Together these habits make systems that bend without breaking and let builders deliver value rapidly and reliably. ...

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