The Red Gate tag line has been Ship Often...Ship Safe, which works great for developers. Make the changes to code as fast as you can and get them deployed. Keep things smooth (or safe) with a routine and a standard way of deploying code. Everyone wins, right?

When we were rehearsing the SQL in the City keynote last year, we came to this line in the script. I wanted it changed. As a DBA, I need to Ship Safe first. If I can do that, then I'm happy to Ship Often, as often as changes can be tested. I haven't ever worried about changes being made too fast, as long as they can be made safely.

These two principles seem to be fundamentally at odds with one another. Certainly there is some tension and conflict, but if those pushing through changes can follow a well engineered process, then dangers shrink. If the people responsible for stability and availability accept the changes coming through a process, then they can accept them rapidly and more often.

Ultimately the closer we move to an engineering process, the more likely that we can deliver software at a higher quality level and quicker. However we need to define our engineering processes using the best practices and knowledge we have, and then stick to the the steps we've decided upon. Only then can we Ship Safe, and Ship Often.