I found myself sending a somewhat frustrated email to my team this evening, due to the current project's automated build being broken. Having thought about it a bit more (probably a little late, for that matter), I'm finding myself asking - "Why is it so important that the build not be broken?". After all, what's the worst that could happen if the build is broken for a night? Given any average night after we leave the office, there's really nothing going on and there's rarely anyone staying late to test our builds - even when their is, we deliver an official package that we know is already built properly. So, why does it matter so much that the build not be broken? I guess the answer to that lays underneath the hood a few layers, down to where the code is being written. And to completly answer the question, I think we first have to understand what we are paying attention to.
We aren't an "Agile" shop by the commonly accepted definition, but we do have a lot of agile practices in our team and we're constantly adding more. As one example, we are using the idea of Continuous Integration to constantly monitor our codebase and provide quick feedback on the state of our code. Our specific implementation isn't quite to the "extreme" (punn intended) that some places are, but it's still an important metric for us. We specifically use CruiseControl.NET, and are quite happy with it. It provides integration with our Subversion repositories, nAnt build files and nUnit unit tests; plus it provides a convenient web dashboard and System Tray application to monitor the status of our builds.
The point of our continuous integration is to get some fairly quick, constant feedback on the status of the builds. When we commit our code, CruiseControl notices it through a check of the subversion repository, pulls it down to a specified location on our build server and runs our nAnt tasks to build and deploy the code. It's the actual build and deploy process that we really want to pay attention to. With multiple developers on our team and most of them adding files to the projects on a regular basis and/or modifying existing files on a constant basis, it's a common occurance for code to no longer work. Everyone understands that even with all the right TDD practices in place, something is going to break sometime, and we need to be on top of those breaks so that we can fix them as quickly as possible. The concern is not that the code will be broken at some point, the concern is that when the code breaks we won't know for an extended period of time. If this occurs, and it does take time to find out about it, we may be running up against a deadline or we may have a larger ammount of code to fix than would have been required if we found it earlier. By having a quick set of feedback, we can catch the problems sooner, correct them and move on before they become huge issues.
But what benefit does continuous integration provide, if the team doesn't care about the build being broken? If the development team is serious about creating quality software, then the entire team should care about the build being broken. Even if the team does not use any sort of continous integration practices, a broken build is never a good thing. If a manager wants to see progress, or if a developer does an update from source control and can no longer work, then there is lost time while the team waits around for the build to be fixed. Lost time and lost productivity look bad... looking bad too many times has a negative effect on how the team is viewed by management... Management is responsible for performance evaluations... I think we all understand where this is going. :)
Back to the original question now, - "The build is broken, who cares?"
The answer should be, "The entire team cares." If we create an atmosphere where a broken build is a bad thing, then we have created a more productive team. More productivity means the team can move on to the big issues faster and not spend time wondering if the build will work the next time we try to deliver it.