Posts

You may have heard the comparisons of software building with accounting. Accountants create dense, technical records, and utilize the method of double-entry to keep their bookkeeping in order. Every transaction is entered twice so the balance sheet always sums to zero. Accountants check balances frequently, catching mistakes early. A discipline enforced by law in many regions around the world. Test-Driven Development (TDD) is the developers’ double-entry bookkeeping. Writing an executable automated test first and then running it frequently lets developers detect and identify errors immediately, keeping the feedback loop tight, and preventing cascading failures. ...

The agile software development approach includes a core set of principles, practices, and disciplines that help teams build software projects. It offers a shared language and clear expectations for how people behave toward each other, the project, and the deliverable. Some of the practices seem odd at first, but they’re the backbone of success. Over the years some of the practices have become common place and others have been left by the wayside. I’ve seen teams shrink their focus and efforts on TDD, Refactoring, Simple Design, or even Pair Programming. And so resulting team becomes a weak shell of its true potential. ...

The standup meeting is a tool, not a ritual. It’s optional and doesn’t need be scheduled every day. Do what makes sense for your team. Keep it timeboxed. 10 minutes should be enough. Even for large teams. Traditionally, the format has been to use a simple formula: Each builder answers three questions: What did I do since the last meeting? What will I do until the next meeting? What is in my way? No discussion, no posturing, no deep explanations. ...

A breaking continuous build system is a Stop-the-Presses event. We pause our work and gather around to fix the failing build together. I’ve frequently seen teams silence the alarms by turning on the “ignore” flag on the failing tests, or deleting the tests all together. Just to stop the “nuisance” notification emails. But that only hides problems, and can lead to broken software being deployed. Instead, it’s important for the team to be encouraged and given the ability to prioritize fixing the tests, rather than being pressured to quickly meet some other completion deadline. ...

Many teams accept it as normal, and “usual”, for the build to break now and again. Instead, foster a team culture where it’s considered an “unusual” thing. Before checking in code, the builder needs to run the unit tests and acceptance tests. If the build breaks, something unusual has happened, and we switch focus to fix it immediately. A simple visual trick that can help accelerate the discipline of keeping the build in good health: Create a visual calendar year grid diagram for the build, and mark a green dot for each day with no build failures and a red dot for each day with at least one build failure. ...