Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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.
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.
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!!
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.
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?