Tech Kindred

I’m going to make a seemingly arbitrary claim.  In some sense, the debatable nature is the point, in that hopefully it spurs some thinking.  

If it takes you longer than a third of your development time to deploy a web application, including acceptance testing, then your deployment process is broken.

I’m calling this the one-third rule.  Obviously, the one-third rule is linear, which means it isn’t a big deal for large apps that have taken > 1 year to develop.  However, as dynamic languages and convention based MVC frameworks dramatically reduce development times, sometimes in the range of 2 – 3X, what seems simple can be a tall order for some shops.

For example, Oracle Mix took ThoughtWorks and Oracle AppsLab about 5 – 6 weeks to develop.  Under the one-third rule, that means roughly 2 weeks for deployment, which in the Mix case we did simultaneously with development.  Most enterprises that I’ve worked with during my consulting days couldn’t come close to that – in fact, many places would still be trying to requisition hardware at the two week marker.  Worse yet, if I create a skunkworks project that takes me only a day to create, it implies a near instantaneous setup, which I’ve never seen.

We can argue about whether the number is one-eighth, one-third, or one-half, and if there are bottom and upper limits.  We can also argue about what constitutes a deployment, especially considering whether the release is internal or external and the extent to which it includes user acceptance testing. But all the caveats belie the point.  Fundamentally, as development times decrease, deployment times will increasingly become a constraint.  The companies that take innovation and time-to-market seriously will get this and optimize their deployment. The companies wed to the world of 500 person teams and 3-year development cycles will not.  Period.

Dynamic languages, like Ruby, and faster development cycles will affect several concerns beyond the act of writing actual software. For smaller projects, the other constraints can make the productivity gains in development marginal. If it takes you 3 months to deploy anything, then saving a month of development time on a three-month project is good, but not great.  Conversely, shaving a month off the same project when it takes you two weeks to deploy has a greater relative impact.  Organizational shifts need to occur in the business and operations groups to take full advantage of what happens in development.  Deployment is a good starting point, as it should touch several pieces of your process.  

Lastly, if you don’t like my rule of thumb, then come up with your own.  Just make it controversial.