The Bar Is Even Higher Now

Thursday, April 5, 2012

It's been just over 8 years since Michael Feathers wrote "The Bar Is Higher Now".

I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you're paying a price for it.

continuous delivery

It's fascinating to talk to IT professionals from companies around the world and realize what a wide range of workflows are in place. In some shops there are very few automated tests, no automated deployments, and 30 page manuals with instructions for setting up a developer workstation to reach the point where you can begin to work on an application.

On the other side of the gulf there is Amazon (a deployment every 11.6 seconds), Etsy (a new developer commits to production on day 1), and Flickr (they deployed 97 times this week (scroll to the bottom)).

The rapid feedback cycles and agility gained through ruthless automation are a strategic advantage for those companies. I also suspect the developers are happier and far more productive compared to the companies where 20 people are on-call at 4am waiting to help with a new deployment that's been 10 months in the making.

Perhaps the new bar to reach for is this:

If I can't walk in and commit to production on day 1, then you are not as good as you think you are, and you are paying a price for it.

Interesting goal, don't you think?

gravatar Matt Wrock Thursday, April 5, 2012
Great post! This really resonates with me right now. I've seen shops implement automated in the past with both ops and dev terrified later to find it was one of the best things that ever happened to them. Currently, I've spent the last few weeks on a powershell sabbatical from my C# job, converting over 50 pages of deployment and setup documentation to a new, condensed deployment doc in the form of 1000 lines of powershell and some TeamCity love. My hope is that the goal you mention above will very soon be a reality.
gravatar Scott Thursday, April 5, 2012
@matt - awesome!
Didrik Finne Thursday, April 5, 2012
Here's a question to consider. What do we do to assure ourselves that our automated deployment scripts are doing what they are supposed to do. Do 1000 lines of script need tests?
gravatar Roy Moore Thursday, April 5, 2012
Agreed! Thanks for putting this together, Scott.

The sad part is that the big shops who push infrequently believe they ae protecting their company by working in that manner.
gravatar Matt Wrock Thursday, April 5, 2012
@Didrik An excellent question. In C# I'm a pretty strict TDD'r. I've heard of it being done in PS, but I have not been doing it. I do have BVT style tests that run at the end and ping each "key" endpoint via a http get and expect a 200 back. The builds fail if that 200 does not return. I think one danger of going the strict TDD route here is that in the end OPS will own and tweak this and I honestly dont expect them to keep up tight unit test coverage.
gravatar Ryan Cromwell Thursday, April 5, 2012
@matt @didrik
Automated Tests remain in place to provide confidence. What information or questions could you ask about your production environment at any time that would give you confidence that would give you confidence?

Surface that information and you've won today's battle
gravatar Nick Friday, April 6, 2012
This happened at my current job (deployed on my first day just for the sake of it due to high agility) and is the most productive and most enjoyable place I have worked at.

I'm with you K Scott :)

Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!