Earlier this week, I was invited to speak about DevOps at the University of Queensland Computing Society.
I finished my Bachelor of Information Technology degree at UQ in 2002 (ahem, not a typo) and I looking back, DevOps - or frankly any software delivery content - was not a feature of that degree. I believe that's changed a little... but not to a great degree. So I was keen to hopefully share some of that knowledge.
Usually I'm speaking to seasoned software engineers, or at least those with a bit of industry experience. In this case, most people watching were students. It meant a different audience than I'm used to, and a slightly different way of presenting the content - not making any assumptions about what people have experienced.
Regardless of your experience, if you're new to DevOps, this recording is a good place to start.
The video is below in its entirety, and after that a few of the main points I tried to emphasize.
There's a lot of detail in that talk, but there are three main things I want to emphasize:
1. It's important to learn what DevOps actually is.
The ideas, theory, literature, and research around DevOps are important. Incredibly important.
The ideas, theory, literature, and research around DevOps are important. Incredibly important. The core concepts and principles around DevOps should form the basis for everything you do as someone involved in software delivery.
It's extremely common for new concepts or practices in software engineering to be followed without much introspection. Just following the guidance and checking the boxes.
Implementations of agile software development give plenty of examples, from daily standups to definitions of done to velocity and burndown charts.
They may all be useful, but without introspection from a position of knowledge, you're just following the bouncing ball.
So it's super important to know why these practices exist and what they're designed to achieve. Not every project or team is the same, so what works in one place might not work as well in another. If you know what the core goals are, you can adjust appropriately.
Where do you get these core principles?
Outside my own colleagues (Abel Wang, Donovan Brown, etc.) the main people I look to are: Dr Nicole Forsgren, Gene Kim, and Jez Humble.
2. You don't need to be in charge to improve your DevOps practices
You don't need to change the org chart to have an impact.
There are things you can do with your day to day work, even as an entry-level developer, that can improve your company's DevOps position. You don't need to change the org chart to have an impact.
If you've looked at the literature and research, you'd know that improving your software delivery correlates strongly with improving your company's performance. So why wouldn't you?
This can involve strategies like setting up a CI server, choosing a trunk-based branching strategy, or could even be as simple as writing unit tests before fixing bugs or writing "dead code" (that's a fun one - see the video for details).
3. Customer value should always be your target
If you're not sure whether you're creating value, what do you need to do to work that out?
Is the work you're doing right now likely to lead to something valuable for the end user. Either now, or in the future. If you're not sure whether you're creating value, what do you need to do to work that out?
It's common for developers to simply implement the features they're given on the backlog. But do you know if those features are valuable?
Acknowledging that you won't truly know if something is valuable until it's in the hands of customers is really important. Hypothesis-driven or experiment-driven development takes that acknowledgement further. You can't prove out a hypothesis without measuring the result, and an experiment is useless if you don't observe the results. The same should go for your software.
There's a lot to DevOps
There's a lot to learn in this field, and it's not something you can buy or implement in a short period of time. It's a process of continuous learning, evaluation, improvement, and introspection with that goal in mind - providing value for the end user.
I'd love this to be a starting point for both students and experienced professionals getting into DevOps.
So watch the video and let me know if it helped. I'm always available on Twitter at @damovisa!
More Resources: https://damo.ms/devopsresources