To start with, this comment:

… having a branch implies an extra complexity and thus extra work …

is wholly false. I often hear it from people who aren’t accustomed to branching, but it’s still wrong.

If you have many developers accumulating changes locally, their local changes constitute a de-facto branch of the main repository.

When they finally push, this is a de-facto merge.

The fact that your branches and merges are implicit doesn’t remove the extra complexity you’re concerned about, it just hides it. The truth is that making this process explicit might help you (plural = the whole team) learn to manage it.

Now, you say

no one is allowed to check-in while to build is red

but in this case the build can never be fixed, so it can’t be quite accurate.

In general, if it’s reasonable to build locally (ie, the build isn’t too big or slow), developers should do that before pushing anyway.

I assume this isn’t the case, because then they wouldn’t push broken builds in the first place, but it’d be great if you could clarify this point.

In general the answer to

how to stay efficient when a build is almost always broken

is: stop breaking the build.

developers… accumulate their changes locally… You can see the vicious cycle.

It’s vicious indeed. Accumulating changes locally is a big red flag indicating that something is severely rotten in dev process. It sort of trashes the whole purpose of having a version control system.

As long as you want to stay away from changing the process or other people behavior, the most natural solution would be to set up your own branch and use it to “accumulate” your changes (to be further integrated with team branch when you get a chance).

Actually, if there are more guys like you, you can even collaborate and establish shared development branch to freely exchange your updates without being interfered with incompetent management ideas. Branching allows for many different ways to simplify teamwork.

• ^{Side note, every time that manager does or says something that forces you to avoid commits, to keep the code locally, translate their words into bold and plain “I am incompetent”.}

please keep in mind that I am a developer, not a manager, and can’t change the process or other people behavior much…

For the sake of precision, you actually can, these are matters of influence and communication skills and one doesn’t really need to be in position of power to change things to their liking (search the web for something like “manage up” if you’re interested in more details).

However that’s rather cumbersome and effort consuming and I can perfectly understand if one simply prefers to stay focused on coding, with little involvement in politics – so if you don’t want (even though in theory you can), that’s understandable. 🙂

I’m sensitive to the notion that you feel powerless to change the environment, but I think this situation is a serious challenge to your professionalism as a programmer.

What would happen if a surgeon stored dirty scalpels with the clean ones? What would happen if a plumber didn’t test the pipes he installed? What would happen if a violinist always played out of tune with the orchestra?

Why should programmers be exempt from teamwork and common courtesy? As a member of that team, you share responsibility for the result. It’s irresponsible to ignore the team as it sabotages it’s own efforts.

I’m curious where the rule that “no one is allowed to check-in while to build is red” comes from? It’s a good rule if that then focuses everyone on fixing the build. I would try to lead by example and help fix the build whenever it’s broken. Let’s face it, you’re not getting anything else done anyway. If this annoys you, then I would suggest voicing those concerns. The voice of someone actively trying to improve a situation has more influence than the guy who grumbles in the corner.

I think that as long as you think that you are “just a developer” and therefore you cannot change things you are going to suffer from this problem.

What you need to do is that you need to revert every commit from the repository every time when someone breaks the build and then tell that guy that he just broke the build and that needs to stop. You also need to explain this situation to the manager and tell him that your team’s productivity is suffering because of this problem.

You need to do whatever you can to change the process better and rather say you’re sorry later instead of asking for permission.

I think that you and your team are in a situation where the process needs to be changed and you cannot work efficiently with that broken model. I also think that it’s your responsibility to do something about that problem when you have recognized it. If no-one else’s going to do anything about the problem, you are the one who must!

I can relate to your plight, I faced a similar situation with my most recent project at work. We ended up implementing sort of a “hot potato” system where the developer that most recently broke the build had to babysit/nanny/monitor it until it was fixed AND passed all of our verification tests.

This was successful because the build and verification tests routinely took ~4 hours, so breaking the build meant you lose half a day in doing real work. Needless to say this resulted in developers using branches more efficiently before merging them into the trunk. For most developers, the previous mindset was “I’ll just let the CI build system notify me if my code is broken.”

A simple change to the CI system would do it: any change that breaks the build gets rolled back automatically. Even better, let the CI repository become a staging area, where changes only get pushed through to the authoritative repository when the build is green. Tools like Gerrit can help here.

Two other things could help here:

• can your team smoke test a CI build locally? If you check that you don’t break the build — or at least don’t break the build in common ways without having to commit and trigger management and team ire.
• there are many ways to define broken builds depending on how you architect CI. This includes defining broken — under heavy development we don’t consider failing tests a break but rather another goal to work towards.

But you should really look at branches.