Alex Wilson and Benji Weber
Alex Wilson has been a software developer at Unruly for approaching two years, during which time he has had the opportunity to experience and solve scaling issues with their software development methodologies. He takes particular delight in the application of both Continuous Delivery and Xtreme Programming practices to the ‘DevOps’ process, made easier by Unruly’s stance of emphasising the value of generalists over specialists.
Benji Weber is a developer at Unruly – a marketing technology company – where he has been delivering working software to production almost every working day for the last few years. He has had the privilege of working with a variety of different technologies and teams, experiencing some of the different challenges and opportunities for continuous delivery in different team sizes and tech stacks. Benji has a particular interest in Extreme Programming practices, Continuous Delivery, and Domain Driven Design, along with a wide range of technology interests.
- How did you get involved in Continuous Delivery?
Alex: I was thrown in at the deep end when I started at Unruly with similar experiences to Benji (deploying early on my first day) – since Unruly is my first position after university I believed that this was just how everyone does it, which I discovered is very much not the case.
Benji: I saw how things were done when we joined Unruly, and a team was deploying multiple times a day. I only later discovered it was called Continuous Delivery and read the book by Dave Farley & Jez Humble.
- What do you see as the biggest advantage of Continuous Delivery?
Alex: CD and automation go hand-in-hand as I see it, and in order to keep our feedback loops tight and enable early decision making we’ve had to automate our processes aggressively. As an added bonus of this, we’re able to quickly deploy servers and applications from scratch with a reduced amount of pain – a victory in its own right.
Benji: It allows us to get feedback on the value of our work in the shortest possible time. Often it is even possible to measure how much money a change is generating/saving after releasing it. Therefore it minimises the amount of time we spend building the wrong things.
- What do you see as the biggest challenge in Continuous Delivery?
Alex: As with any methodology, it can be hard to get buy-in from other developers when the benefits aren’t immediately obvious and it’s difficult to understand the value of doing CD without having tried it first-hand. It’s also easy to fall into the “tooling trap” where you focus too much on tooling and not enough on actual practices – you can easily implement a decent CD workflow with nothing more than a set of shell scripts.
Benji: Like most things in software development, the biggest challenge is communication. Helping new team members understand why we do CD, and how to do it effectively, and maintaining awareness in the team about the reasons for what we do. There are constant forces pulling us away from CD. We add new tests which slow down deploy cycles. We are influenced by hype and “best practices” from the rest of the software development community which don’t play well with CD.