“Are you a software developer that spends hours setting up your development environment? Do you hate the fact that it works on your box but not theirs? Do you have to spend hours setting up other people’s environments to work with you? Does this sound like your job? DON’T FRET! Docker is here!” - Mr. Joe Sales for all things Docker.
This is what software development looks like today. Advertisements of shiny new toys. Toys advertised that will take your business to the dream heights that are just around the corner. Toys that will make not just your developers lives easier, but operations and managerial staff as well.
I myself have been bombarded by this throughout my career. I am not 100% sure if the industry was always like this, but there seems to be a serious amount of white noise right now for such toys.
It doesn’t take much for me to investigate these toys, but I pride myself on the fact that it would take a serious amount of scrutiny for me to properly use one of them in my job. There is a lot of hard things to overcome in software development, but I think ignoring the impending white noise of new toys is one of them.
Given this, and the amount of white noise it takes for me to pick something up and take a proper look, something made me stop and ask “what is this DevOps thing then?”.
DevOps is something of a hot topic right now. Since its inception – around the 2008 mark when the term was coined by Andrew Shafer and Patrick Debois – DevOps is the buzz word that is thrown around by many corporations. Due to all this hype, I thought I really needed to find out what all the fuss is about.
At the time of this writing I will admit to myself that I don’t have an overarching amount of experience when it comes to agile practice. Some things I have seen work, and some have baffled me. But the idea of DevOps has really struck a chord.
“Get to the point, how the frick is this going to help ME?” - Impatient developer.
Glad you asked. DevOps is designed to bring people together, and make lives easier during software development. That’s it. It’s not really about Docker, Kubernetes, Ansible, Vagrant (or any other sizzling technology), it’s – like all agile lessons – about bringing people together.
Ask yourself a question, what is the most challenging thing about your current workplace? (other than constant distraction of course)
I think about my current work, and how I currently work, and I try and understand the pain points that I have. “Redis is so complicated, how do I just get this to work?”, “Hey Jack, could you show me how to setup Redis?”, “How do you want to deploy Redis?”, “Do you need to prep Redis for the testing environment?”. These are the pain points that I think DevOps is trying to mitigate. (By the way, it has nothing to do with Redis, that’s just an interesting topic I’m currently having fun with.)
We - the developers - love to program. Musing over object-oriented principles, functional programming, shiny new toys, or whatever the best thing is to get you back into your “flow”. I love these topics as much as the next developer, but I don’t think it’s what truly makes a great software developer.
“So, what makes a great software developer?”
Value
I think the most important measurement of a software developer is the value they give to the client. Not just making a client happy, but challenging the client on what they see as improvement, but which really might be time wasting.
Value is the essence of DevOps to me. All of those questions I had to solve, wastes precious minutes of my day. Is your company on weekly release schedules? Monthly? Quarterly? Yearly? Why not deliver value to your client every single day, even multiple times a day?
What is the measure of success for a DevOps oriented company? Is it about the ability to deliver constant value to a client, and the client’s customers, daily? Is it about quality assurance?
It’s not about Docker for me. It’s not about continuous integration. It’s not a shiny new toy. It’s about value. Will continuous integration add value to my client? Would a simple deploy script suffice? Isn’t value to the customer why we get paid in the first place?
It’s not about tools. It’s about value.
Useful Links
https://sdarchitect.blog/understanding-devops/