The prevailing attitude in software development still seems to be that if something is difficult or expensive (or even just not much fun), we try to do it as few times as possible. Â This usually means deferring it until as late as possible.
Examples:
- merging and integrating the work of multiple people
- merging and integrating the work of multiple teams
- execution of tests
- testing the integration of components
- deploying into a production like environment
- deploying into production
Most of these things are difficult and expensive, and the temptation is to make more rapid progress early in a project or release by deferring these things until late. Â Unfortunately these things are also very difficult to predict – in complexity and effort. Â This means that we often find that we have a significant amount of complexity late in a project or release, just as the pressure on the team starts to rise to deliver. Â This inevitably leads to delays being announced very late in the delivery of a project or release, or the team to abandon quality.
I don’t want one day to be significantly harder or anxiety-inducing than any other. Â I don’t like the ‘deployment day’ being a time which people dread, or merging the work of multiple teams to be an unloved task which is risky and error-prone.
My goal with CI is to do these ‘hard’ tasks as often as possible, to invent ways to make these things easier, and to keep this up until the ‘hard’ tasks are painless and risk-free.
Hey Evan
Quite right. I think this is an important principle for delivery in general – it’s #4 of my list of principles of delivery in my book: “If it hurts, do it more frequently, and bring the pain forward” – you allude to the latter half in your post, but I think it’s good to bring it out.