97 Things Every Software Architect Should Know

Chapter 15. Commit-and-Run Is a Crime

Niclas Nilsson is a software development coach, consultant, educator, and writer with a deep passion for the software development craft, and he loves good design and architecture. He is a cofounder of factor10 and the lead editor of the architecture community at InfoQ.

—Niclas Nilsson

IT'S LATE IN THE AFTERNOON. The team is churning out the last pieces of the new feature set for the iteration, and you can almost feel the rhythm in the room. John is in a bit of a hurry though. He's late for a date, but he manages to finish up his code, compile, and check in, and off he goes. A few minutes later, the red light turns on. The build is broken. John didn't have time to run the automated tests, so he made a commit-and-run and thereby left everybody else hanging. The situation is now changed and the rhythm is lost. Everyone now knows that if they do an update against the version control system, they will get the broken code onto their local machine as well, and since the team has a lot to integrate this afternoon to prepare for the upcoming demo, this is quite a disruption. John effectively put the team flow to a halt because now no integration can be done before someone takes the time to revert his changes.

This scenario is way too common. Commit-and-run is a crime because it kills flow. It's one of the most common ways for a developer to try to save time ...