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.

We keep repeating "you have to pull first" (this is git and github by the way). Then you code a little, then get your tests to pass, then commit, then pull and push again. We give tutorial links, try firm / hard. The latest changes broke 2 dozen tests. We document everything. What other things can we do to help folks. We require passing tests. Right now we are tempted to rollback all of todays changes which wouldn't be popular. I'm not a big fan of that harsh an approach to management but perhaps a 'final' warning that we will do that next time is now required. Failing that it's clear they need to fix broken tests, right? We fixed them last time so that didn't 'take'...

share|improve this question

migrated from stackoverflow.com Jul 21 '11 at 1:41

This question came from our site for professional and enthusiast programmers.

    
Just fire them ;-) –  zerkms Jul 21 '11 at 1:16
    
cattle prods?... –  Mitch Wheat Jul 21 '11 at 1:16
    
I agree with zerkms if it's that bad, you need new programmers –  Andy Jul 21 '11 at 1:40
    
Is this a corporate environment or a open-source project to which amateurs contribute? –  blubb Aug 3 '11 at 14:30
    
You have a continuous integration server? It can tell people when their commit was broken –  user1249 Apr 20 '12 at 21:10

4 Answers 4

up vote 8 down vote accepted

Get your team to solve the problem and give them the autonomy to do so. Gather your team and do your best to state the problem or situation and goals clearly. State it like requirements, defining what needs to happen without specifying how. Developers are problem solvers so make this a problem to solve. This means you will have to listen and may have to give up on your ideal solution, but it your team owns the solution in they will be more likely to follow the solution they came up with.

Your requirements may be something like

1) Automated build runs each night a 9:00, so all tests have to pass by then. Ask the team how to enforce this (maybe if you break the build you have to bring in doughnuts :)

2) Builds are deployed every Wednesday, if tests do not pass by Tuesday then we miss the release and delay until the next window. How can we enforce this?

Whenever I do this with my team I find that they come up with a better solution than the one I've been dictating and they enforce it with each other which allows me to focus on more important things than enforcing the rules.

share|improve this answer
    
Well, if a broken build means donuts... then I'd be breaking builds all days. ;-) –  Spoike Jul 21 '11 at 7:41
    
You would have to buy them every day ;) –  Turnkey Aug 3 '11 at 12:22

Sounds like you are doing it wrong - I mean the general git workflow. Here's a couple of suggestions:

We keep repeating "you have to pull first" (this is git and github by the way). Then you code a little, then get your tests to pass, then commit, then pull and push again.

Why is everyone committing into the same branch? That's so svn :). Let them develop in their own branches, specific for developer or feature. Don't worry about what they break in there, but demand that everything must pass tests and be top-notch in general once they merge their changes to production branch.

That way a programmer can develop isolated code in peace (even for a couple of days when working on a feature) and worry about integration and tests later, when he decides to put changes into production.

You can take it one step further - don't allow developers to push directly to production at all and give them a script instead which will allow them to push changes only if all tests pass. Simple.

Right now we are tempted to rollback all of todays changes which wouldn't be popular. I'm not a big fan of that harsh an approach to management but perhaps a 'final' warning that we will do that next time is now required.

Again, what are branches for? In this case you can:

  • create a "bugfix" branch from "production" branch

  • delete broken code from "production" branch

  • fix broken code in "bugfix" branch

  • merge "bugfix" back into "production"

What's so harsh about it?

In general, try to improve your version control workflow (perhaps hire a git consultant to help you with that?), that should stop programmers from committing broken code into production.

Of course, bad workflow isn't an excuse for committing broken code, but take it from a developer's perspective - it's very easy to break code when several people are working on the same app at once and everyone's committing to the same branch. Especially if they do a huge commits and tests are brittle, but I don't know if that's your case.

share|improve this answer

Have you tried making failures more visible? A public build radiator? E-mail committer/team/company (well, the last one maybe isn't such a good idea unless you have a pretty small company..) when a build breaks, describing the commit contents and committer?

Try to make feedback loop as short as possible. If developer knows that she broke the build 15 minutes after the commit vs tomorrow, there is huge difference in terms of being able to react.

share|improve this answer
    
Agree with this. You should have a monitor that can tell you whether a build break / success. –  Rudy Oct 14 '11 at 10:41

If the problem is that your team constantly break the build then you should all sit down and discuss the problem.

As a manager you should make it clear that if you don't have a buildable artifact at any time in the build server then you are not delivering anything. What would be the effects of not delivering anything? Then let the team try to solve the problem with what processes, practices and tools your team needs in order to have everything deliverable by the end of the day. Also make sure the team does not have any other pressing issues during this day or else those will take precedence by default.

There are multiple ways of doing this, but ultimately the team has to do it, so give the team enough time (like a day or two) to do this on their own.


... and if they still suck you need better programmers who have the discipline to do this kind of work.

share|improve this answer
1  
Terminate the worst developer with the most lack of discipline. You should be clear that you won't tolerate breaks in build. –  Rudy Oct 14 '11 at 10:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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