Continuous Integration trades fear for instant gratification

Automated build and test (a.k.a. Continuous Integration) has rapidly become the way to develop IT systems. There are many reasons for this (a maturing IT industry, availability of C.I. tools, etc), but I think the most powerful driver is the sheer enjoyment a developer can derive from the C.I. process, in particular:

• Instant feedback on how good you code is (as measured by unit tests), determined in a risk-free environment
• The ability to fix a bug (found by unit testing or other automated testing methods) while the program flow, class structures, etc are fresh in your mind.

In short, Continuous integration is a perfect match for a world where instant gratification is the default expectation.

Now, contrast this to the working environment for anyone maintaining a complex IT system built 10-15 years ago, i.e. a legacy system without automated testing facilities:

• Every code change is associated with fear ("Will this change have any unwanted side effects?", "Will I lose my job if a destructive side effect sneaks past the fallible, manual testing stages into Production?")
• A high percentage of the bugs reported from Production will be of the "Duh! How could we have missed this bug before deployment?" category, quite simply because a completely manual test regime is bound to have incomplete coverage. And that's exactly the category of bugs which make the poor maintainer look incompetent.

If you've tried both worlds, you are not going back. Continuous integration is here to stay.