Commit-and-run is a Crime

?

Commit-and-run is a Crime

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 T He. John is in a bit of a hurry though. He ' s late for a date, but he manages to the 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 has 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 are lost. Everyone now knows so if they do an update against the version control system, they'll get the broken code onto their Local machine as well, and since the team have a lot to integrate this afternoon to prepare for the upcoming demo Quite a disruption. John effectively put the team flow to a halt because now no integration can be do before someone takes the time to Rever T his changes.
This scenario is the 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 for himself, and it ends up wasting other people ' s TI Me and is downright disrespect-ful. Still, it happens everywhere. Why? Usually because it takes too long to build the system properly or to run the tests.
This was where you, the architect, and come into play. If you've put a lot of effort into creating a flexible architecture where people can perform, taught the Develop-ers Agil E practices like Test-driven development, and set up a continuous inte-gration server, then you also want to nurture a CU Lture where it ' s not all right to
??? Things every software Architect should Know
?
?? Waste anybody else's time and flow in any. To is able to get this, you need to make sure the system, among other things, have a sound architecture for automated testi Ng, since it'll change the behavior of the developers. If tests run fast, developers would run them more often, which itself are a good thing, but it also means that they won ' t le Ave their colleagues with broken code. If the tests is dependent on external systems or if they need to hits the database, re-engineer them so they can be run lo Cally with mocks or stubs, or at the very least with a in-memory database, and let the build server run them in the slow The. People should not has to wait for computers, because if they has to, they would take shortcuts, which often causes proble MS for others instead.
Invest time in making the system fast to work with. It increases flow, lessens the reasons for working in silos, and in the end makes it possible to develop faster. Mock things, create simulators, lessen dependencies, divide the system in smaller modules, or does whatever you had to. Just Make sure there's no rea-son to even think about doing a commit-and-run.
Niclas Nilsson is a software development coaches, consultant, educator, and writer with a deep passion for the software Deve Lopment craft, and he loves good design and architecture. He is a cofounder of Factor10 and the leads editor of the Architec-ture community at InfoQ.

Commit-and-run is a Crime