This is a guest post by Julian Simpson. Julian helps bridge the gap between software development and IT operations. He's spent the last 5 years helping people with Continuous Integration, deployment, build tools and version control systems, on the Java, Ruby and .NET platforms. He writes about all this at his blog The Build Doctor, and on Twitter. He has presented at Agile 2007 and XP Day 2007, and QCon London 2009. Julian lives with his fiance and their children in Surrey, UK. In his spare time he likes to cycle, garden and play poker. Though not at the same time.
Does your code work on your computer? Nobody should care. Sorry.
I'm sure it's good code (you wouldn't be reading this blog if you were one of the 80% of developers who write terrible code and never read about their profession). But the finest code in the world is irrelevant - unless it helps someone do something. We should be measuring our success as software professionals by how many projects we deliver, to users who gain something. We don't achieve that as often as we should: The Standish Group's latest 'Chaos' report points out that over 24% of of IT projects fail outright, and 44% under-deliver. We mess up 6 out of every 10 projects. That's pretty lame.
There's a load of reasons why we fail: poor project management, unclear objectives, etc. Of all these reasons, my least favourite is writing some great software and then struggling to deploy it. You might expect to get away with this in a Waterfall project. But Agile projects deserve better. It's very common to see months of iterative development cumulate in a big-bang deploy: except that sometimes it's more of a whimper than a bang.
My verdict is that in general, we suck at getting code from developer to production. But why?
For every blog about deploying code into production, there's 50 on coding techniques and tools. It's critical that we learn how to improve the craft of software development. When 6 out of 10 I.T. projects fail, you know we need to do something. But why the emphasis on coding and not say, deploying, configuring or maintaining software? To me it seems that many developers aren't given the incentive to care about writing code that works; they write code to pass whatever bar we set them. If that's getting your code to pass through Continuous Integration or QA, then that's what they'll do.
On the other side of the wall, the people who run that code have a very different set of objectives. Reduce cost, and keep services available to support the business. Oh, and did we mention reduce cost? It's unusual to see an operations team with the incentive to get new code out to the business as soon as possible. Even if they do, they're often burned:
- Some people have the job of deploying new software into production. They don't see it working in test systems, they just get documentation and a bundle of software to deploy. Which might even work some of the time.
- Other poor souls are told that they are responsible for the performance of software that they didn't write. They control the environment in which it runs, but they have no influence on the performance optimisation of the code.
Do you honestly expect those people to welcome your new release of code with open arms? To them new code represents a threat rather than an opportunity.
Don't go buying into the stereotypes of lazy developers or pedantic systems administrators, though. All these people behave in the most logical way, given their incentives and constraints. Operations teams become bureaucratic to mitigate the risk of unknown software; and developers are always under pressure to deliver more. What are they going to let slip?
The root cause of all these issues the massive wedge that's been driven between the people who write software, and those who run it. We need to break that wedge apart.
I never wanted to choose between my career in Unix Systems Administration and the alternatives like software development. It was hard to keep my options open - the industry needs to label you as one or the other. As Ross Pettit writes, we obsessively pursue scale in the IT industry. As an organisation that wants to scale, perhaps is seems normal to split up into so functional teams. As your organisation grows, those teams become departments, and then divisions. Perhaps you outsource a division, so now your code flows across organisations. In that context, it's okay to have the developers in building A throwing code across the wall, over the car-park and into building C where the administrators sit. There's a certain logic in having teams of similarly-skilled people sat together. They certainly learn more about their narrow specialty. But it impedes us in our goal of getting the code into production. Which is the only reason we're here.
We need a renewed focus on the last mile of software development.
The last mile turns your code from a bag of bits into a running investment portal, or e-commerce platform. The people you'll meet on the last mile know about configuring and running code reliably so that it delivers a return on investment. That rewards your entire IT organisation. Gus Power spoke about getting systems people to pair with developers. It always begins as a difficult process but pays dividends as the guys from the first mile and the last mile gain understanding and share experience. I believe that smaller, cross-functional teams can deliver so much more than scaled up organisations - because we're at our best when working as one team. Collaboration is the way out of this mess. And that's why I'm going to the DevOpsDays '09 conference in Ghent, Belgium this October.
To Smash a Little Piece of the Wedge…
(images by mshades and Seattle Municipal Archives)
Twitter -
Subscribe -
Newsletter -
Bookmarks
Latest, greatest and favoritest posts:
Checklist for the Agile Manager (Presentation)
Empowered, Whether You Like It or Not
Great Managers Have No Secrets
