Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
29  
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 Rizos Nov 8 '11 at 11:17
2  
What are your team rules for this situation? –  user1249 Nov 8 '11 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 Rizos Nov 8 '11 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 Nov 8 '11 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 Nov 8 '11 at 17:01
show 13 more comments

closed as primarily opinion-based by MichaelT, Bart van Ingen Schenau, Corbin March, Yusubov, gnat Sep 7 '13 at 5:43

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

16 Answers

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.

share|improve this answer
98  
its also polite for the first developer to buy doughnuts to make up for breaking the build –  jk. Nov 8 '11 at 13:44
3  
+1 for doughnuts :) –  Luke Graham Nov 8 '11 at 13:54
16  
I would like beer rather than doughnuts. –  Loki Astari Nov 8 '11 at 15:21
2  
Doughnuts could be offensive to the gluten intolerant. A $5 gift cards to Best Buy, on the other hand... –  Christopher Mahan Nov 8 '11 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. :) –  Dan Neely Nov 8 '11 at 18:22
show 5 more comments

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.

share|improve this answer
9  
"...not on blaming the responsible." Unless it's a regular occurrence. –  Shawn D. Nov 8 '11 at 14:06
add comment

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.

share|improve this answer
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 Nov 8 '11 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. –  MPD Nov 8 '11 at 14:49
add comment

Communicate

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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!!

share|improve this answer
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 Nov 8 '11 at 14:33
add comment

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.

share|improve this answer
show 2 more comments

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.

share|improve this answer
add comment

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 :)

share|improve this answer
add comment

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).

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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 ^_^

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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