Recently Matt Hilbert, from Redgate Software, wrote a piece on our blog about our journey to DevOps. It’s a great read, summing up some of the things that we’ve learned in our journey across the last decade. Matt is a great writer, and it’s worth a few minutes of your time to check it out and think about all the things that we’ve been through.
I’ve known some people at Redgate for 18+ years, and I’ve worked there for 12, so I’ve had the chance to see quite a few changes. When I started, teams worked for long periods of times, in what is really a waterfall methodology. They went through substantial phases of development, testing, and beta releases, with Brad McGehee and myself having plenty of time to learn a product and then know it would be stable for a year or so.
That slowly started to change, as Matt describes, with teams moving to new methods of building software, experimenting and learning. The Prompt team was one of the most ambitious, working in pair programming and finding ways to release almost on demand. Over time, other teams caught up and built some amazing processes. We even had two teams working on some products, with alternating two week sprint cycles to allow them to release every week. That was an impressive coordination of software development teams.
Even today, I’m constantly impressed by teams. They aren’t all always rock stars, but they often exceed my expectations. I will see some slowdowns when teams change their people, process, or tooling, but then they will leap forward. The Data Masker team has been impressive lately, with some fantastic productivity improvements being added to the software. I apologized recently for not taking the Data Catalog team seriously for almost a year, but they have done more than I ever imagined with that tool in the last six months.
We do continue to improve our software development skills at Redgate. We do release often, but really, we try to also improve the quality of our software, improve the skills of our developers, while working to retain talented individuals and help them enjoy their chosen career. We still produce bugs, we never get everything done as fast as sales, marketing, or even me, would like, but I do think that the last ten years has been an incredible growth as set of software development teams. Now our challenge is more closely aligning all teams to work in a loosely coupled, but tightly integrated fashion.
DevOps is really a better way to build software for most organizations and teams. It often doesn’t change a lot about the actual code we write, but it does get developers, infrastructure staff, and management to rethink how we work, especially how we work together. That’s the hardest part to get through to many customers. This isn’t an install-a-tool-and-things-are-great system. Tools do help, but your attitude, your focus, and your willingness to work as a team are more important.
Read about our journey. We’ve taken 1,000 steps, but there is more for us to learn, change, and implement as we move forward. Think about how you would want to change things at your company, and maybe pass this along to your manager. It’s not easy, and it might not be quick, but it’s an incredible journey. It’s also very much worth the time and effort you put into it.