I like Continuous Integration – a lot. Small incremental changes, continuous testing, continuous builds: these are Good Things. They provide statistics, things you can measure your progress with. But Continuous Integration requires an investment on the part of the development team, the testers, etc. There are, however, a few things you can adopt right now so, I decided to give you a list of things I think you should adopt.

Fail Fast: Keep the cycle between coding and knowing whether your code works as short as possible. Make it as easy as possible to know whether code works – ideally with excellent coverage (both functional and code) in unit tests that can run during a compile cycle.

If something doesn’t work, you want to know it before your developer has time to get up and fetch a cup of coffee. If that’s impossible, he should know by the time he gets back to his desk.

It should also be clear how the failure is related to the code. That means:

  1. Self-documenting code
  2. Self-documenting test cases
  3. Test cases that test one thing, and one thing only

Keep the build fast I’ve worked on projects where hitting F7 (build) meant going home for the night. This is not a good thing: it gets developers to write a lot of code without every building, let alone testing. That, in turn, slows down the development cycle which has all kinds of nefarious effects.

Automate testing Note: not just tests: testing. You want to get tests running without anyone having to think of starting them. You want to automate feed-back to your developers. You want to tell your developer (politely) that he’s made a mistake and should repair it before he inflicts the code on others.