Monday 17 March 2008

Closing the Gap

Last week I posted about the gap between infrastructure and software.  I figured it might be a nice idea to talk about how we could address that gap instead of just having a whinge.

Thinking about why this gap exists in the first place it seems to me that most organizations are structured to create it.  They have this "developers in one team, infrastructure guys in another" kind of philosophy - organization by trade.  Then battle commences and they throw work back and forth over an imaginary brick wall between the groups.  Here is my code, no we can't support that it doesn't have monitoring feature X, OK it's back, no it doesn't work on this server, but it worked in the development environment... ad nauseam.

The next thing most companies try is fixing the problem with a hefty application of good ole' fashioned process.  This inevitably brings with it gates (signoff points in the development cycle) that engineers need to navigate.  Bob needs to sign off the monitoring capabilities, Tim needs to sign off the failure testing, Steve needs to sign off the compatibility with the live environment etc.  Congratulations, you've now built natural choke points (and if you're not careful key man dependencies) into your product delivery process - and we all know a machine can only move as fast as it's slowest part.

So what did you learn through your use of gates?  You learnt who needed to have a say in your product development, that's what.  This means the journey wasn't a complete waste of time - unless you stop here.  Now that you know who needs to work together to build your product in the best way possible why not team them up like that?

Organize ownership by product or feature or service - whatever the basic unit of your engineering output is.  Cross discipline teams containing all the skillsets necessary to design, build, test, deploy and support your system on a per service/feature basis will yield you the most appropriate solutions in the shortest possible time.  Embed all the necessary capability in every team - you'll need it every time anyway the only difference is the size of the communication gap.

I've suggested that product = software + infrastructure + operational know-how to run it.  That being the case why shouldn't a product team be made up of developers, testers, system administrators, architects and product owners?

No comments: