Most developers know you should never break the build. Most will also take care not to do so. And when it happens, they know it should be fixed as soon as possible. But why is that? Why is the build so important? And what arguments can we give to the more sloppy developers who don’t agree?
Why Do We Have a Build?
In it’s simplest form, the build picks up the latest commit to source control, and compiles the code. In more mature projects, extra steps can be added like:
- running automated tests
- performing code analysis
- versioning artifacts
- publishing artifacts
An automated build process is an important part of Continuous Integration (CI). It acts as a neutral referee to check the state of newly added code and perform otherwise manual tasks. It allows you to check if the code will work on other machines than your own, and it takes boring tasks out of the developer’s hands (like copying compiled dll’s to some central place for later reference).
So what happens when I break the build, e.g. something doesn’t compile or a test doesn’t succeed? Is it really a big issue? I say yes, and here’s why.
You Block Other Developers
When the build is broken, it’s a best practice to not push anything new to source control until the build is fixed. So the only new commit that can be pushed should fix the build. This means everyone else is waiting for the fix and can’t continue working. This is frustrating and a waste of time and money.
Often, developers can get into a state of flow (i.e. “being in the zone”) where they become very focused on what they’re doing. When developers want to push their changes and they find the build is broken, they suddenly have nothing to do but to wait. The consequence is that they are pulled our of “the zone” and will need some time to get back into that state of mind. Now, getting out of the zone is necessary to remain productive (i.e. going for a walk, standing up and getting some coffee,…). But it shouldn’t be forced on you. It decreases any productive moment you were having, slowing down development.
And because you as a developer are forced to sit around doing nothing productive, it can feel frustrating when the build is broken.
This is not to say that there’s a special place in hell for those who break the build. It happens to the best of us. So shouldn’t we just learn to live with broken builds? Sure! So can’t we just push our changes and fix the build later? Well…
It Leads To Code Rot
A build that is broken and fixed quickly shouldn’t be a big issue for a team. People make mistakes. They write bugs. They forget to run all the tests locally. They have some special configuration on their computer that makes it work on their machine. It’s not a big deal that should lead to punishment.
But when developers stop caring and just continue work with a broken build, this leads to bad situations.
Specifically, fixing the build could take longer to fix the longer the broken build stays around. At first, there might only be one reason the build is broken. But new commits by other developers might introduce new reasons. However, these developers might assume their build is broken because of the first, original cause. I’ve seen this happen, where the amount of failing tests increase over time. When someone finally tries to fix the build, he or she has a lot of extra work to do.
But more generally, a team that doesn’t care about the state of the build will more easily allow other bad practices to slip in:
- bugs remain unfixed
- code becomes unreadable
- the team loses the discipline or care for writing a maintainable app
- the application becomes more and more the codebase noone wants to work on
- development of new features slows down
These are all symptoms of a team that no longer cares. And a team that no longer cares leads to bad code, slower development, lost money, people leaving, and a very hard time getting the spirit back up.