When it's Ok to break the build

For some teams, and some developers, breaking the build is a terrible thing that should be avoided at all costs. (Not just because you may have to buy everyone donuts if you do.)

I used to be fine with anyone breaking the build (and not just because I like donuts.)

This came with some qualifications:

• You shouldn't do it deliberately.
• You should be making small, frequent changes that are less likely to break anything.
• You should fix the build ASAP if you do. (You don't go home having broken the build as you'll be blocking other people.)

But, all in all, I'd not sweat it if someone broke the build. I'd rather they were doing that because they were shipping code and not sitting on massive changes or holding back because they were worried about breaking it.

For the most part, this approach has worked well for many years.

But recently, I've encountered behavior that's making me reconsider this idea.

The behavior I've seen is developers using the CI process as a way to validate their code.

I've seen attitudes like:

"If it fails, I'll find out when the CI process tries to build it as part of the PR automation."

"I won't bother running the tests myself as the CI process will do it for me."

"If the CI process fails, it will create a new issue, and if I fix that, it looks like I'm closing more issues."

These thoughts scare me:

• They indicate a lack of professionalism and pride in the work being done.
  (Why wouldn't you check that it works before saying you're finished?)
  
  
• They indicate a lack of respect for the value of testing.
  (Why wouldn't you check that there are no unintended consequences of the changes you've made by running the tests? - Ok, It may take a while, but surely it's better to be safe than sorry. If running them takes a long time, isn't it better to know about problems sooner? And especially to know about them before you get engrossed in whatever the next thing is.)
  
  
• They suggest you can work the system to look more valuable and productive, and presumably, the organization rewards this.
  (This sounds like you've found a way to make your life simpler at a cost to the product, the company, and the team/your peers. That doesn't sound healthy. It sounds like your manipulating the data to appear to be closing more bugs when actually you're the cause of many of them.)

Don't be like that.
Make an effort to ensure that your code works, doesn't break anything else or have unintended side effects, and that you're helping your team to all be as productive as possible.

So, when is it ok to break the build?

If it's an accident that you attempted to avoid, and will fix it quickly.

When is it not Ok to break the build?

There are many reasons, but my current bug-bear is that it's not ok to break the build if you do it because of laziness.