Builds and quick feedback.

The main reason why I like tests is because they helps me be right! That is why I write them! If I am right, the code I write will be good and will not only serve me, but also the person paying me for the code. But as I write more and more code for more and more people, I need faster indicators. I need better indicators and I need consistent indicators. Hence we have build status indicators.

There are a number of variations on these indicators. Build lights, build status shown up on monitors etc. The primary purpose of these indicators is not to tell you that the build is broken; their primary purpose is to tell you that quickly! There is no point having a build indicator that takes its own sweet time! You might as well run tests locally if that be the case. But as you keep adding the tests to the suite, the time between builds will get larger and larger! What you can do is:

• Split builds across machines
• Split builds internally based on application being tests
• Throw hardware at the builds.

Also, a build indicator is useless if the environment it runs on does not mimic your version of production. We cannot ship your laptop, and hence their is no point writing code for it. You must write code keeping your production environment in mind and the build machines should mimic the environment as well. Other wise, your tests are useless. Let me repeat that. If the build machines you run your test suite on do not mimic production, your tests are useless.

A common problem that arises with build indicators is what to do once you have the feedback! Should you drop what you are doing, and try and fix the problem or finish the current work to a point where it is committable and then try and fix the problem? I don’t know! Which ever works best for you! But the build should not be left stagnant for more than an hour after it is broken! Whether the build gets fixed in an hour is not relevant, but someone working on it within the hour is! if you were connected to a ECG and the graph showed nothing, would you be so laid back about it?

Show your business interests that it is in their interest for you to fix the build. You cannot tell them and expect them to agree. Your continuous integration server (for example Hudson , *cough* I meant, Jenkins) should be producing graphs based on several important metrics. Use them to convince management. You are doing a disservice to your code base if you expect to waltz up to your management, soliloquies about importance of green build indicators and get them to agree! Talk to your business, card it up, and make sure you are working on it.

Lastly, be the first to fix a build. Its fun and its cathartic. Fixing things, no matter how small or how trivial, gives you a good feeling. Do it!