Would forcing developers to fix at 3 AM the build they broke undermine motivation? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

Breaking the build is a bad thing. Different teams take different measures to encourage their members to avoid breaking the build at all costs.

• Some measures are moderate. For example Joel Spolsky tells that his Excel team had a rule that “whoever broke the build had to babysit the builds until someone else broke it.” (Joel Spolsky. Joel on Software, page 20).

• Others are more drastic. For example, Steve McConnell reports that “[s]ome projects have developers wear beepers and require them to fix the build day or night if they are responsible for breaking it.” (Steve McConnell. Rapid Development, page 384)

Forcing the developers to wake up and come to work at the middle of the night to fix the build they've broken looks like an excellent opportunity to focus their attention on the reliability of the code they commit and encourage them to check it twice.

At the same time, programmer analysts usually favor personal life (fourth top priority motivation according to Table 11-1 in Rapid Development page 252, fifteenth for managers and general population) and may not appreciate the risk of hearing their phone ringing at 3 AM.

Personally, it doesn't annoy me to go and fix my mistakes at 3 AM, but only if I work for a company with flexible working hours. Most colleagues I know will refuse to come to work at 3 AM, no matter the reason and no matter how important their presence is for the company.

What is the way of setting up severe measures like night and day beepers while keeping motivation high? Or such drastic measures should be avoided at all costs, and be used only when there are no other choices, to the detriment of the motivation of team members?

Answer 1

Broken builds happen. It is impossible to completely avoid them. Developers may be distracted while merging changes, or may simply not have run all of the tests in a very large system where a complete test run may take a significant length of time. Whatever the reason, it is important to realise you cannot always ensure that they never happen.

Developers don't want to be called back outside of office hours. I think this is pretty much a given. Quite aside from any effect on morale, they're likely to do whatever they can to avoid this happening. As it isn't really possible to 100% ensure that they never break the build, I suspect the effect that this kind of system will have is to make at least some of them reluctant to check in their changes close enough to the end of regular hours that they risk being called back. If your full integration test suite takes an hour to run, that means people will be reluctant to check in after 4pm, meaning there's a full eighth of the day that they're not checking in for. This will result in many large check-ins early in the morning, with an increased risk of the build breaking (because the risk is approximately proportional to the size of the check-in).

So, no, I don't think this is a good strategy. I suspect it will actually have the opposite effect to the intended one. Joel's suggestion you quote in your question is a much better idea.

Answer 2

I suspect this may be a subjective question, but it's unlikely that forcing people to fix builds late at night/early morning would do anything to improve morale or motivation.

Further, it's likely that work done at 3am is not going to be of the same quality as work done during normal hours, even factoring in programmers' odd schedules. There will also be fewer (if any) people around to do code reviews, or whatever else is part of the bug fix process.

Finally, it seems like a solution to a problem you shouldn't really encounter, with proper environment setup. We use Git along side a CI system that allows branch builds, so that developers are running a build on a CI agent every time they make a commit on their branch (including unit tests). This ensures that when a feature branch is merged into trunk, the code has already been merged (trunk -> feature branch), built and tested on an agnostic system. There are very few legitimate reasons for a build on trunk to fail in this case.

So, in the end, work smarter, not harder.