Software, Continuous Delivery

Chris O’Dell is a Senior Consultant at Contino. She is an advocate of Continuous Delivery and co-organiser of the London Continuous Delivery Meetup group and the PIPELINE conference. Chris is also interested in Web APIs, microservices, distributed systems and Agile development practices.

We sat down with her to discuss her background and the challenges of planning software delivery in the face of the unknown and the uncertain!

Why don’t you tell us a bit about your background?

My ambition was to become a games programmer, which led me to study computer visualization and animation at university. But the field is so competitive! My first job ended up being with a document composition company. It was essentially mail merge carried out on an enormous scale. It involved taking data exports from bill and phone companies and writing programmes that would take all the data and merge it into documents ready for printing. I learned more than I ever thought I would about mail! Most importantly, I had my first ever testing experience: the tap test. You have to print documents in such a way that when you tap the envelope the address is not dislodged from the little polythene window in the envelope. Crucial.

I was essentially working as a business analyst, working with the development teams to spec out code. They would then write the code - very old school! But I didn’t want to be a business analyst, I wanted to be a software engineer. So I joined the team working on a C# importer that was meant to replace COBOL. That’s where I started with .NET (the first version!).

I then spent four years in a web agency, working on a multi-year project for a big client. I remember that they wanted us to plan a year’s worth of work up front. Five of us spent two days stuck in a room constructing a gigantic Gantt chart. Obviously, this was a horrendous experience and the chart itself was a collection of complete and utter lies. None of it came to fruition.

That was a rude awakening to the difficulties of planning software delivery up front!

But while I was there I set up their Continuous Integration platform (we used cruisecontrol.net). I took it upon myself to make sure that all the builds were green, which is what sparked my interest in all things continuous.

I learnt the importance of keeping the master green. We were using Visual Sourcesafe, which didn’t support ‘ branching’ in the same way as today. This meant that all development was trunk-based, which is amusing because these days people don’t think that that’s possible! We had to check out one file at a time. After you checked out a file, it would be locked on the central server so no one else could work on it. Sometimes the team in the Ukraine would go home with these files locked and no one would be able to do any work on certain files until the next day!

I then worked for a small startup called 7digital, learning first-hand about test-driven development (TDD), Xtreme Programming (XP), Continuous Delivery, double loop learning, lean processes...it was an awesome job. I’m grateful to have had many fantastic mentors: Rob Bowley, Paul Shannon, Gonçalo Pereira, Hibri Marzook and many more!

That was where I did my first public presentation on Continuous Delivery, which led to further involvement in the London Continuous Delivery Usergroup and the PIPELINE Conference, with further speaking opportunities developing from that one talk! I currently co-organize the PIPELINE Conference and give presentations on CD-related topics.

After 7digital I joined Just Eat, where I spent a couple of years working with CD and web services at scale on AWS. People think that Just Eat is “only a website”, but a huge amount of technology is required to get all the orders to the restaurants. It’s probably the only e-commerce business out there that has a turnaround time of 45 minutes from taking an order to having that order fulfilled! There’s absolutely no room for error. And these 45 minute cycles are almost entirely concentrated in only three hours (between six and nine) three days of the week (Friday to Sunday). The scalability and resiliency of their platform is incredible.

I’ve heard that you wrote a book?

Yes, I’m the co-author of a book with Matthew Skelton of Skelton Thatcher Consulting titled Continuous Delivery with Windows and .NET. Farley and Humble wrote a book on CD in 2010 that was very Linux focused. Many people still think that CD can’t be applied in a Windows/.NET world and many clients of ours think it’s only applicable to Linux. Matthew and I wrote the book to show people that it’s totally possible.

What benefits are there to doing CD on Windows?

You gain all the benefits of CD without having to change your operating system or processes. And Microsoft has done a lot of work to make things a lot easier: greater testing support, preinstalling PowerShell on servers, introducing VSTS, adopting Git and so on.

Why did you join Contino?

The next level of progression for me was to take my learnings from places like 7digital and Just Eat and to apply them to other places that are looking for change. Hibri Marzook, Contino Technical Principal, with whom I worked at 7digital recommended the company to me and it looked just right for what I’m looking to do.

Why is planning software delivery so difficult?

The reality is that software is an unknown, complex problem. You can’t copy and paste solutions from one context to another, if that were the case you could just buy software delivery solutions off-the-shelf. The reason that engineers are brought to bear on a product is because the space that you are trying to fill is unique to you, or requires an unknown twist of some kind.

All software delivery is a process of discovery and you can’t plan very well for discovery.

Why do companies think that they can?

Because they don’t see software delivery as a process of discovery but as an expenditure, something that must be paid off. They think it’s like constructing buildings, which is a better-known and more predictable domain in which you can do up-front planning that will result in something that resembles the original plan. But construction works because you know in advance what houses or office blocks look like. With software this is not the case. Nor is it easy for the customer to visualize and then properly communicate what they want. This is why people resort to bizarre analogies to describe what they want: “It’s Facebook for dogs”, “Uber for helicopters” etc. They can only describe what they want with reference to things that already exist.

But there has to be some kind of direction upfront?

Yes, but it’s more goal-setting than planning. And you always have to feel it out as you go. It’s like wanting to travel to the North Pole but not knowing how to get there.

This is why Agile works. You can only plan what you can see, so by only planning in short phases you gradually learn a bit more, then plan a bit more, then learn a bit more and so on. You can be reactive because the loops of learning and planning are short, with the goal dictating the direction of the planning loops throughout.

How come this ideal is so difficult to realize in practice?

If you’re going through a process of discovery, you’re also ‘discovering’ the costs that come with that, both in terms of money and time. People prefer to work from a position of certainty – based on budgets and time-bound expectations – which can be hard to reconcile with the nature of software delivery. The certainty instead needs to be sourced from regular updates and from driving more stakeholder engagement in the discovery process. Customers themselves need to be involved in designing the goal and guiding the process to the end, rather than expecting a finished solution that looks like what they thought they wanted at the beginning.

What’s the best way of selling this idea into engineers?

Engineers usually want to be proud of the work that they create. They want it to be useful and impactful. Rather than wasting their time coding something that will never see the light of day. Agile and CD let them know if they’re on track to achieving that.

What’s more, the ownership, responsibility and accountability that come with these ways of working increase team performance. I’ve been on teams that were tasked with maintaining the “worst” application. But because they had full ownership we were able to turn it into the best-performing application in the company and everyone all of a sudden wanted to work on it.

That pride is infectious!

What are the main drivers for change towards these ways of working in an organization?

They vary from wanting to become leaders in their field or avoid getting eaten up by competition, to reducing costs or simply jumping on the latest trend in the hope that it solves whatever issues they’re having. And all of those are valid reasons...but change is hard!

Why is change hard?

Change is hard because, at its core, it’s always a question of changing humans, which goes hand-in-hand with the not only the unknown, but with critical self-reflection (which humans typically shy away from!). Changing technology is pretty easy compared to changing the unpredictable and funky nature of people.

What do you find rewarding about this work?

Many things! I really like building things and solving problems. What interests me right now, for example, is distributed systems. I got the bug from Just Eat because they had really high peak variability and reliability. Building systems with the requisite level of resilience is an intriguing challenge!

How do you go about building things?

By being aware of existing computer science theory and standing on the shoulders of giants! At the minute I'm reading about the Paxos algorithm and CAP theorem, for example. There’s a lot of theory that I try to put into practice.

At Contino, it’s more about CI/CD and helping to make companies and people become more productive. It’s fantastic to watch low-performing teams turn into high-performing teams. I don’t believe that anyone really wants to perform poorly, they just may not have had the support they needed. That’s what is interesting about the work that Contino does, it’s really about making that drastic change in performance by enabling client teams from within.

What do you get up to outside of computer science?

I’m currently studying maths through the Open University and I’m learning to play the cello. I also have two cats, Loki and Fenrir (the son of Loki).

So not nerdy at all.

Nope.

Great, thanks so much Chris!

No problem!

x

SIGN UP TO OUR UPDATES

DevOps Insights Directly to Your Inbox!

Join thousands of your peers and subscribe to our best content, news, services and events.