If you're at IMVU, the day 1 goal for a newly hired developer is to turn the crank through the entire build and release process, getting a bug fix into deployed software. (This is not a post about continuous deployment, although that's a fascinating topic in and of itself. And for those who are skeptical that such a process can coexist with a useful or valuable product, there's always Flickr.)
In organizations I have experience with, time-to-first-deployed-bug-fix is not a useful way to look at ramping up developers within the organization. Deployment is a rare event. Even if it's every three months that's rare compared to the checkout-build-bugfix-test-checkin cycle that forms the meat of the development cycle.
In organizations that don't practice continuous deployment, time to first bug fix check-in is a similar way of measuring one element of ramping up -- how long it takes a developer to be able to turn the crank for one revolution of the process. I've seen it take a day in organizations that had a well defined build process, to over a week for a product with a hairy complicated and mostly manual install that took a lot of training -- and much longer, several weeks even, in organizations that are scared to touch their code.
I'm particularly thinking about this because I'm about to be the New Guy, starting work at a new company. How long will it take me to file the first bug or write the first test? What will that tell me about the team and technology I'm going to immerse myself in?
No comments:
Post a Comment