One programmer committed some work to the SVN repository, then went home. After he left, the Hudson automatic build failed. Another programmer saw this, and after looking through the code changes, detected that the problem was the absence of one library. He added this library to SVN and the next build completed successfully.

Did the second programmer do the right thing or should he have just waited until the first programmer fixed the issue?

  • 31
    Question: One programmers member asked a question. Another member read the question and saw some syntactical and grammatical errors, so he decided to edit the question and correct them, to make the question a little bit easier to read. Is what the editor did right or should he had just waited for the poster to fix the errors?
    – yannis
    Commented Nov 8, 2011 at 11:17
  • 2
    What are your team rules for this situation?
    – user1249
    Commented Nov 8, 2011 at 11:23
  • 4
    @nahab Oh, don't worry, I'm not saying that it's a problem :). Just that in a community, as in a team, members helping each other should be encouraged. Also I don't think that a developer breaking a build is unprofessional, even if for a minor bug, these things happen to the best of us.
    – yannis
    Commented Nov 8, 2011 at 12:10
  • 11
    The whole idea of having Hudson in the first place is because humans are humans and will break the build once in a while. You just want to catch it early. It could be argued that the programmer in question should have verified that the build built before going home.
    – user1249
    Commented Nov 8, 2011 at 12:40
  • 14
    This is much more easily comprehended if you consider the opposite--If the build is broken, slowing down the entire team (even at home, after hours) and you can fix it but make a deliberate choice not to due to some point of procedure, should you be allowed to keep your job?
    – Bill K
    Commented Nov 8, 2011 at 17:01

16 Answers 16


It depends to some extent on how your team usually works, but I would say that was fine. Keeping the build working saves everyone else time.

It's polite for the the second programmer to drop the first an email to explain what he has done, just in case a specific version of the library is needed or there is some other complication. It's also a slightly more subtle way to point out that they had broken the build.

  • 103
    its also polite for the first developer to buy doughnuts to make up for breaking the build
    – jk.
    Commented Nov 8, 2011 at 13:44
  • 17
    I would like beer rather than doughnuts. Commented Nov 8, 2011 at 15:21
  • 2
    Doughnuts could be offensive to the gluten intolerant. A $5 gift cards to Best Buy, on the other hand... Commented Nov 8, 2011 at 17:13
  • 1
    @ChristopherMahan would either result in a fight between all the team members over who gets it; or if given one team member like the implicit distribution from a donut box in the break room is a much more expensive proposition. And in any event, a Best Buy gift card could be offensive to anyone who used to work for Circuit City or CompUSA. :) Commented Nov 8, 2011 at 18:22
  • 1
    What can you get at Best Buy for under $5? Commented Nov 8, 2011 at 20:23

It depends.

  • Is the bug so obvious that adding a library is the way to fix it? Sometimes the fix is in finding a workaround not to need that library.

  • Is the project in a phase where all changes must be linked to an existing ticket? If so, did you file a ticket? Has that ticket been assigned to you?

Anyway, focus on fixing the bug, not on blaming the responsible.

  • 9
    "...not on blaming the responsible." Unless it's a regular occurrence.
    – Shawn D.
    Commented Nov 8, 2011 at 14:06

Yes it's okay. However, it's unprofessional for the original programmer to go home before testing wether the build would compile.

Your reputation is 100% in your control. Stuff like this tarnishes your reputation and trying to polish a tarnished reputation is very difficult.

  • 2
    +1 for putting the onus on the first developer to test the build. The second paragraph really isn't true or relevant. Other people can damage your reputation, either intentionally or not, even when your behavior is completely above-board.
    – Caleb
    Commented Nov 8, 2011 at 14:17
  • 6
    It is entirely possible that the original programmer had the library on his machine, but the machine doing the auto build didn't. Yes, the library should be in SVN, but this can be a really subtle problem to not even notice.
    – mpdonadio
    Commented Nov 8, 2011 at 14:49


There is no strict rules (beside your own team rules) for those scenario.

Dev2 should be able to tell dev1 he can fix his error, neither one of them should fear something resulting from this exchange, they are part of a team.


Why not? If your product is more important than fixing blames, it is certainly all right. Although a build failing because of library change is pretty lame and you need to reprimand the developer for not testing it.


Build failures happen. If it's important that a daily build happen then I would fix it and then request that the developer that checked in the broken code to review the fix the next day and ensure that the code is now as it should be.

As has been said, the guy who fixed it should probably email the guy who broke it and detail what the fix was.


My motto, is don't commit to SVN after 3pm that way you can always fix your own build failures.

If you do not fix his/her build failure, then everybody else's build will also fail. I would fix it to save time in the long run, but make sure they are aware that you had to fix it.

Having some sort of 'point the finger of blame' script is a good way to do this, or make the person who breaks the build buy donuts!!

  • 2
    Our CI tool actually has an option to send e-mail to the developer who broke the build (in addition to the rest of the team).
    – TMN
    Commented Nov 8, 2011 at 14:33

Someone needs to fix it and the first programmer should not have gone home without first making sure that he had not broken the build. However, for such an easily fixed problem, calling him back to fix it himself would be extreme.

I agree with Luke Graham's suggestion of sending an explanatory e-mail, although I'd say it's more than polite - it's basic communication.

  • With integration builds sometimes taking an hour or more depending on the complexity of your system, you'd have to implement a "commit cutoff" every day to ensure that the last build of the day will occur while everyone's still around. Even then, people have doctor appointments, kids' soccer practice, etc. and need to duck out immediately, regardless of build status. Agile says that work should be at a sustainable pace and should not be a drain on the workers. Keeping them there till 8:00 to watch a build succeed is contrary to that.
    – KeithS
    Commented Nov 8, 2011 at 14:55
  • @KeithS: True. But I've found that, regardless of when I leave, the most likely time for me to break the build is when I'm in a hurry: right before lunch, right before a meeting, right before the end of the day. So I think it's a "personal best practice" to not commit anything when there isn't enough time to watch and fix the build afterward. Commented Nov 8, 2011 at 16:19

Yes yes yes! It fosters collective code ownership and sets a kind of healthy peer-pressure in the team to keep a high standard and not let a broken window scenario develop. A bit of communication to let the other developer know is a good idea.


I think it's OK to fix obvious things - i.e., if you are 100% sure the guy whose code you're fixing would make the same - or substantially the same - fix. If the fix is more complex, it is usually polite to talk to the person whose code you're fixing - it may be that you misunderstood the intent or the reason for breakage is not what you thought it is, or maybe he intended another fix but for some reason couldn't commit it just yet (life happens, you know :).

In general, the rule usually is: you break the build - you fix the build, but there are exceptions, especially if the fix is obvious and/or the person responsible is unreachable.

Of course, if you have the case of serial build breaker - especially with the pattern "checked in, went home, build broken for days" - the responsible person needs to get some talking to about why CI systems and tests exist and how one should check before checking in :)


Things happen. The failure to add a new code file (whether source or compiled) to Subversion is probably the most common cause of broken builds, assuming it worked on the developer's computer. At my last job with a CI environment, even the most senior guys sometimes forgot.

I think, if another person was able to fix the build and thus keep the team humming along, that's fine. I do think the programmer who went home needs at least a friendly e-mail stating what happened, and to remind him to make sure that new code gets added before commits. If it happens often, maybe make that a minor offense punishable by the "dance of shame", to help reduce occurrences (and lighten the mood).


It depends on Team dynamics, but in an ideal world everyone on the Team would "own" the whole project, all of the code, and consequently, all of the bugs jointly. So if you find a problem you fix it, and communicate with the originator of the bug only if there's some specific added value to the code in doing so.


It's OK to fix unless this is a regular occurance in which case I would have the boss call him and make him return and fix it himself.


It depends, it depends...

As programmers, our work is to get things working, not to judge people. So I'd say that the best thing you can do is to fix it, or if it is not obvious, just roll back the changes and let the first programmer know so he can fix it later.

Anyway, having the latest guy that broke the build to wear a weird hat is enough to pay more attention the next time ^_^


In some environments, this is very rude, and for good reasons. In other environments, it's expected, and for good reasons.

In still other environments, it's very rude or expected for very bad reasons.

It largely depends how critical a broken build is versus how critical a verified correct build. And to some extent, it depends on how obvious it was that the fix was the right fix and the only one needed.


First, 'went home' is an anachronism. Programmers don't go home anymore -- they are just either online or offline. You could ping and wait.

More seriously, there are actually two parts to the question. 'looking through the code changes' is fine; rest may not be the right thing to do. What if his judgement of a missing library was wrong?

Not the answer you're looking for? Browse other questions tagged or ask your own question.