Imagine two gentlemen, Simon and Phil. They work in a car factory. Their stations are right next to each other, but they rarely talk because they are quite busy. And frankly, they don’t have very much in common.

Simon’s job is to assemble the driver’s door. He welds the frame together, assembles the delicate window risers, puts on the cushion and attaches the nuts and bolts to the hinges.

Next up is Phil. His job is to attach the door onto the car. He takes the door, aligns the hinges and tightens the bolts. Then he connects the electric cables and makes sure the lock works - just like he has done dozens of times today. And just like he will do hundreds of times tomorrow.

The guys are both very good at their jobs. Phil has no idea what’s behind the door’s cushion, or how the cool electric window riser works. Simon, on the other hand, couldn’t care less how the door is attached to the car. And that’s perfectly fine - they’re just doing their jobs. They work well together, mostly because nothing rarely changes on their manufacturing line.

What if Simon and Phil were building software? Instead of just assembling the door, Simon’s job is to make the door better. In fact, from now on, every door he puts together should be better than the previous door. One day he’s told to drastically change the frame to make it lower and shorter - bulky cars are no longer in. Actually, just this time, he should weld the hinge on the top side of the door, because marketing thinks some clients like gull-wing doors. And Simon does just that; they are relatively easy changes for him.

Phil is not part of these discussions. He’s expected just to take what’s been given to him, and make it run. Can’t be that hard. He shouldn’t need to know how the door is made. It’s not his job.

But should it be his job? How do you think Phil copes attaching a door that’s not the same size as the door before it? What about the door after, which is nothing like the previous doors? Perhaps Simon should’ve thought about how the doors are attached when doing the changes? Why doesn’t Phil know anything about the changes, until the moment the door appears in front of him on the manufacturing line?

The very nature of software delivery is to make changes and improve. People writing the code and the people running it need to collaborate, or the value chain is broken.

How do you improve this?

As you might have guessed, the answer is DevOps. But what is DevOps?

There are nearly as many definitions of DevOps as there are people working in the industry. The definitions I have seen range from “a new job title for ops guys”, to “a way of living” and beyond.

I think DevOps is a methodology; a set of best practices and tools to increase communication, and deliver better software.

For me, DevOps is about the ops team attending software architecture meetings from the get-go. It’s about having the development team participate in the out of hours rota. Thinking about how the application is deployed, maintained and monitored before a single line of code is written. DevOps is about QA preventing defects proactively, thinking of quality as a feature of the delivery process, instead of merely ”finding bugs”.

DevOps is about breaking down silos, sharing responsibility and building tools to collaborate effectively. It’s about continuous improvement - making sure we have feedback loops in place to know what we can do better.

We have a shared goal, after all. We are doing business. We need to build and ship solutions that somebody is willing to pay for. More often than not this means delivering a set of features by a certain date within a limited budget - the axis of evil, if you will.

Without Phil knowing what Simon is doing - and vice versa - that is often an unattainable goal.