The Chef Win Series is a response to: "How has Chef changed our operations for the better, in the past 2 years since our shop adopted it?"   Example:

Take A Couple Days...

We're all familiar with the drill, we've all done it dozens of times. New guy shows up, or you're the new guy, or you take someone else's workload, or else you hand off some chunk of key development work to a customer...

"Here it is. Take a couple days to get your dev environment set up, then we can go over how the codebase works and deploys."

We're still in the early stages on this one, but it's an important piece for us because we see potential chunk of our future market coming from micro-contracts on micro-services. That demands dev environment handoff, back to the customer that hires us.

Take a Couple of Minutes...

Instead of trying to match your dev enviroment to mine so you can continue development of my project, how about fire up this dev VM, and leave your own box untouched?  Git clone the project 2 minutes later, at 10 minutes you are in full development mode - no excuses, no special tweaks, no dev deployment hickups.

This kind of thinking is not possible in the old world, but it isn't too big a step for a Chef shop.

Not Even On The Chef Marketing Radar

I would point out that the problem this solves is so big that other [unmentioned] shops have made it an entire fee based product line, complete with training seminars, documentation sites, the works. With Chef, it's none of that. "Here, just fire up this VM that Chef built." A cookbook. No more.

And I'd be willing to bet that Chef the company doesn't even think of it as a big deal? This is a side effect of having such a powerful platform, you can't even think of all the cool stuff it can do.

Transformation?

I've blogged about the transformation of the development world into this search for the unicorn developer - that one guy who is a so unique and so cool that having him on your team as a full time employee transforms your development organization. Good transformation for the market to be having.

This automated dev vm thing - by coincidence only - addresses a lot of these same concerns. Because a lot of what makes this unicorn guy so cool is his setup. It might have taken him years to get there, but once he's set up he's the bad-ass, and everyone on the team can try to rise to his level. Sorta, anyway.

So I'll go out on a limb here, and say that this one aspect of Chef's capabilities that could allow the entire marketplace to transform a bit. Because it's a lot easier to pass around a great dev VM than find and hire perfect unicorns.  OK, it's a stretch. But there is some merit to the thought.

Central Administration

One last piece and I'll get off my high horse. Once you have this dev VM set up, the possibility of a centralized problem solving administration piece presents itself.

Please consider the following use case. One of our brightest local guys claims that he NEVER updates Ruby binaries more than a couple times a year. "It's always a three day process. There are always all these recursive binary conflicts, then I have to search and find the latest fixes, and two days later I have a working setup again."  And that's a real quote. It would classify as a PITA except that is just one developer! Multiply that times every dev, or even ops engineer, on a team. That's a huge chunk of cash.

What if this was done by a single guy instead, and distributed as a VM? Hmmmm. Worth considering.