Posts

Sometimes the most honest estimate answer is “I don’t know.” That’s useful — but incomplete. Good estimates mix what you know and what you don’t. A common technique is to use relative comparisons (e.g. The estimate to build “Change Password” is about half of building “Login”), another technique is to use probability ranges (“between 5 to 15 days, most likely 12 days”). Both of these approaches can give managers, product owners, and stakeholders some meaningful information without pretending certainty. ...

Within a team if a player falls, the team needs to step up and cover the gap and keep the ball moving forward. When Bob gets sick, Jill steps in to finish Bob’s work. But this can only happen when Jill knows what Bob was doing and where to find his code. So we need to cross-train deliberately and make sure important knowledge isn’t siloed to just one or two people. And we need to encourage each team member to make it their responsibility to ensure other teammates can cover for them. ...

Make Testing a Non‑Event In our day to day lives, the quality of our efforts are our own responsibility. Yet, in most software teams there’s a dedicated group of special people to take some of that responsibility away from the others. It sounds strange to hear it described that way. When there is a QA phase, then it should be the norm to hear that “Everything works.” And in those rare circumstances when QA finds a fault, the builders should ask, “What in our process let this slip?” and fix that process so that next time QA will find nothing. ...

Imagine a button that lights green if the system works and red if it breaks - and it returns results in seconds. You’d probably press it after every tiny change. That fast feedback would remove fear and makes cleaning code feel safe. When feedback is immediate, you can Refactor, Pair, and apply Simple Design without dread. The Agile practice of TDD (Test-Driven Development) enables this button: tests become the quick signal that lets builders improve the code continuously. And with that habit, the team becomes fearlessly competent and the codebase steadily gets better over time. ...

One of the most common reasons systems don’t improve is the fear of change. We see ugly code and think, “I should clean it,” then we stop because we’re afraid we’ll break it — and if we break it, it becomes ours. This fear freezes teams, lets messes grow, and erodes competence. Customers, users, and managers expect fearless competence: when we see dirt, we clean it. We can make cleaning a regular routine on-going activity by reducing the risks — fast automated feedback, small safe refactors, pairing, and continuous integration. When we’re able to clean confidently the code will naturally improve. ...