Continuous Integration is an attitude

Question: How do we prevent integration pain?

Answer: Continuous Integration.

Well, duh. There’s no longer an excuse for integration pain. It’s been proven time and time again that the engineering practices of XP can work. Now we’re seeing the rise of a new issue: Continuous Indifference.

We were probably always prone to mediating communication with tools – the sheer number of issue trackers that exist are proof of that. With Continuous Indifference you can throw broken builds over the wall, and around the room. “Nope, it’s not my commit that broke the build”.

Combine that with:

  • an organisational addiction to email
  • a few other bloated tools
  • unmotivated developers – day rate contractors or disengaged permies

You have the perfect excuse for people to spent a pleasant afternoon debating who broke the build, and what to bill the debate to on their timesheet.

Screw that. It’s time to start again. Continuous Integration is people collaborating to achieve a shared goal. Continuous Integration is primarily a human practice. If you can’t do it without tools, you’re not really doing it. If your team don’t have the discipline to keep the build green, how will they do with the rest of your project?

It all comes down to attitude. Don’t be the last one to volunteer to fix the build. You’re a highly skilled software practitioner. Act like it.

Continuous Integration is an attitude.

Update: I’ve gone and echoed one of Jim Shore’s posts again.  Bugger.

4 thoughts on “Continuous Integration is an attitude

  1. Chris M says:

    I’d like to venture that contractors on daily rates are also on weekly notice periods and are very likely to be shown the door if things don’t work out. If managers don’t do this they have only themselves to blame.
    I’d also like to venture that contractors help an organisation by bringing in specific skills at the right time. One of my recent managers told me that he hired contractors because the permanent staff were lazy.
    Use your tar brush selectively… 🙂
    Everything else I agree with!

  2. Chris,

    Fair enough. I’ve seen great contractors and abysmal contractors. And you’re right, it is the responsibility of the managers to evaluate both the skill and performance of all their staff, contract or permie.

    I tweaked the post to reflect that.

    Thanks for the feedback!

  3. Banos says:

    But what happens when the managers dont want to put in stuff – like tests – that will break the build? Its great because then the problem hits the environment guys who are rolling out first time integrations into the test environments. There’s def a certain amount of pushing and pulling in this space…

  4. Banos. That makes me angry. We’re split in so many ways: developer vs admin, .net vs Java, Ruby vs Python. Doing that doesn’t help one bit. It’s like pooping on the floor and leaving it for someone else to clean up: Cowardly and embarrassing.

Comments are closed.

%d bloggers like this: