Monday, 8.52pm
Sheffield, U.K.
It’s important not to divorce developers from the consequences of their work since the fires are frequently set by their code. – Mike Loukides, What is DevOps?
This is not going to be a very informative post about DevOps – although I’m not sure how informative the other stuff out there on the Internet is either.
But some of the ideas that I’m trying to pull together here may be useful.
Let me explain.
Imagine we go to see a customer.
We have a brilliant conversation, work out what they need and come away with a plan and a budget.
We resource our project – getting people in place – developers, analysts, project managers, admin staff.
We divide up the work and get going.
People do their bits, pass things around and some time later we start to see finished stuff emerging – perhaps we get a service running.
The developers and project managers are now done – the analysts and admin teams get on with using the system and sort out the queries that result.
And there are always queries – so we need a query management system and there are a few hundred on the go at any given time.
And that’s a good operation, right?
Everyone’s working hard, no?
Well, no. Not really.
Here’s the thing.
Lots of demands that look like work aren’t actually work that should be done.
There are two types of demand: failure demand and value demand.
Value demand is stuff that customers need doing.
Failure demand is what you have to do when things don’t work as expected – and queries are a prime example of failure demand.
What we need to do is squish failure demand rates – and I think the DevOps approach is one way to do that.
Think of an alternative approach to what happens.
A developer works directly with a customer to design and develop services to meet the needs of stakeholders.
When the services are deployed, the developer operates and maintains those services as well.
But, you say, a developer is an experienced and valuable resource – you don’t want such a person doing operations and maintenance.
To which I say they shouldn’t be.
If they’ve driven failure demand out of the system, that is.
Let’s say you’re collecting data on behalf of a customer and the report you get in from a source is always a little bit different each time.
That breaks your data collection process so you need to go and fix it each time.
That’s failure demand.
Now, if this task is handed to an “admin” person then you might tell them to make those changes as part of their job.
You are now paying someone to handle defective materials – driving up your costs.
Instead, why not go to the source and help them generate clean data in the first place?
Maybe have a conversation, talk through what is going on and figure out a way to improve things.
If you fix the cause of failure demand then your system should operate reliably and automatically without your intervention.
Developers want to create things but are less keen to live with the consequences of their creations – that’s for users (lusers?) and less technical folk to struggle with.
And that’s not really that useful.
Instead, hire or train smart people with the skills to both program a computer and talk to people and fix problems.
It’s not that hard – but you have to get better at selecting and training people with the right attitude.
Because you’re asking them to do more than just a job.
You’re asking them to delight customers.
Cheers,
Karthik Suresh
Handcrafted insight 