Sparked by a short Twitter exchange, this time I investigate why a lot of CD implementations (that I've come across) often appear to be half-complete or just fail to achieve CD. What are the root drivers behind achieving CD and why do so many implementations fall short? Is it just ME?

It's a hard subject and one that I've debated with quite a few people. This episode is an exploration of a few themes and perhaps can offer some insights or perhaps is still a work in progress. I certainly have a few more avenues to explore around where the application stops and the CD implementation begins - plus should you design your CD implementation with that in mind.

Really interested to hear your thoughts.

SHOW NOTES

My book list including links to 'Accelerate', 'Continuous Delivery' and Domain Driven Design

https://richardwbown.com/resources/

The original tweet:

https://twitter.com/BryanFinster/status/1587589240321626113

Original post with my quote and Bryan’s discussion of it:

https://riseandfallofdevops.com/5-minute-devops-cd-is-pointless-5c906d0fd164

Bryan discusses many things including “Engineer for Release” on the No Nonsense Podcast:

https://richardwbown.com/bryan-finster-continuous-delivery-no-nonsense-podcast/

QUOTES

02:19 - "in my experience over 25 years working in software on it, I've rarely seen an organization successfully deploy a consistent CD implementation across the whole org." [RB]

02:52 - "continuous delivery is often seen as a holy grail for a firm's digital transformation" [RB]

04:42 - "the organization types should be Westrum generative. That it should be a nurturing, encouraging high cooperation organization" [RB]

05:16 - "So my point is most orgs don't support the concept of CD because they don't change. " [RB]

06:02 - "Because as every good book on the subject says without fail, there is no one size fits all solution for any of this. Plus it takes a lot of work on the journey is really, never complete. " [RB]

07:16 - "Most organizations are not software delivery centered organizations. There's just something that they have to do" [RB]

09:36 - "Pride gets in the way when it comes to building software, but also CD pipelines." [RB]

11:10 - "CD typically is created by a few heroes who understand that complex domain." [RB]

12:34 - "Similarly for CD, perhaps that's too lofty a goal to aim for directly. If we look at this huge program of work that we take on when we start to implement CD." [RB]

14:07 - " where does. the application stop and where to CD begin. But that's a, that's a topic for another time I believe." [RB]

15:47 - "engineering for release, which I really love. This is the concept that you're building your release mechanism even before you've built the first line of code." [RB]

16:01 - "Before you even write a test or a single line of code, you write your pipeline" [RB]

Webcam Recording

===

Welcome to the software delivery club. My name is Richard Bown. This is episode 20. Yeah. And this is a ranty one. This is called Does Continuous Delivery, Deliver or Does Continuous Delivery Have an Image Problem or What's So Good About CI/CD? So this is quite a meaty one. So, as you might know, every two weeks or so, I explore different aspects of the business of delivering better software.

From leadership to strategy technology teams, product systems, delivery, customer. I talk with myself mainly and sometimes with industry experts about important subjects about building and delivering amazing software.

And I read that and thought.

Do people think CD is edgy. I'm not sure. Anyway, I came up with a smart comment And I said, I think CD is edge case rather than edgy. Too many orgs just don't see the point and they probably have a point.

What I was trying to say, was that companies are trying to C D and. Then kind of not getting there and wondering if it's still relevant or important for them. So I'm starting to think that it's got an image problem.

So, yes, I'm saying that the CD is edge case. But in my experience, in my experience over 25 years working in software on it, I've rarely seen an organization successfully deploy a consistent CD implementation across the whole org. Which is if you read the books and if you listen to Brian and perhaps Dave Farley as well.

Certain Dave Farley. That's where the organization really wants to get the most value from a CD implementation. So why is that? Why did orgs not get to a point where they feel they've done CD successfully?

Well, maybe it's not the orgs themselves, maybe with the engineers. Maybe it's the value they're not seeing.

CSO to ignore.

Those are two key books at this point in time in software delivery.

On the first part, I guess we agree that it's anecdotal, but yes, the irrefutable from a data analysis or statistical perspective that organizations that deliver software more frequently do better. That's the underlying thread of 'Accelerate'.

So, I'm not saying CD, isn't a worthy goal, but too often, the leaders of these organizations do not feel they have to change themselves or change the organization to enable CD to be implemented completely. So my point is most org don't support the concept of CD because they don't change.

Some teams might get there, but the overall might not.

So enterprises often don't create the environment that is needed for CD to survive and thrive. They ended up with a mishmash confusion of tools and , and it's very hard, unless policies are rewritten, to make sense of anything like CD.

So this is the drift of my slightly offhand statement. I'm still researching it and looking to prove myself wrong. But my idea and my experience is that we've got ourselves here by being too obsessed with taking it on the latest tool technique. Framework and applying them.

So as orgs, we kind of ignore the idea of the hard work. As engineers, we don't. We take it very seriously. But unless the organization supports that then CD may never be achieved properly.

I continued this thread on Twitter and LinkedIn and got some interesting responses. Most of it was around. Oh, well, you've obviously not read these books on CD before. Or you don't know what you're talking about or. Uh, variety or combination of the two. Well, I have, I have done CICD before I've done it for over 25 years.

And I've written. Hundreds of thousands, if not millions of lines of code. And I'll. Walk the walk for a quarter of a century. Having said that. I've also tried to think about things from an organizational perspective.

Most organizations are not software delivery centered organizations. There's just something that they have to do

So apart from that, apart from the leadership style of an organization which may or may not contribute to a failure or success with CD. How do we get to the situation where CD implementations, aren't really getting to a point where they're achieving what they set out to do in the first place.

So I said that, it had some of these different leadership and something to do with culture. But let me ask you this. Have you ever been in this situation?

Developer 2 says maybe true, but have you considered it from wise perspective. And Developer 2 has another famous author Y, which he may have heard about, you may have read Y's book, but. Isn't particularly familiar with it. And Developer 1 says, yeah, I know Y's stuff, but it's a bit, yeah. I looked into it and I don't believe it's as good as X's perspective.

And it becomes a situation where it's, there's a lot of pride at stake, so people will throw a lot of effort into supporting their claim and supporting their argument around the way that we do things, because I think that's also what we see as software engineers. We want to be able to affect the way where we like to think of ourselves as clever people who can't understand complex processes and implement them in code.

So we get this pride in everything that we do. I want to roll it out through our tooling and through everything that we do basically.

And. What I'm trying to say here is that. Pride gets in the way when it comes to building software, but also CD pipelines.

So that's my first point. Point one pride driven development.

My second point is that CD pipelines CI/CD pipelines. Are usually created by heroes.

If you look at the examples in the DevOps handbook in particular.

You will see stories of brilliant individuals or small teams saving enterprises, millions by creating an implementation for CI/CD or Kubernetes or whatever. And typically when you look at these changes they're not really from a team perspective or the success stories don't tend to come from a team perspective. They tend to be, I or we did this, we were parachuted in, or we created this.

And. That's great. And the figures are indisputable of course, but we see in 'Accelerate' that the more quickly organization delivers, then that's better for the organization.

There are one or two people who gravitate towards that complexity and see that as a great challenge, but typically supporting that longer term is less appealing. And you end up with a team which is tasked with looking after. Maybe a CI/CD estate which is failing potentially, um, when your morning break and tests.

If that's not aligned with the team. Or if it is aligned with the wrong team, perhaps, or people move on. Then things can change. So CI/CD degrades over time, unless its maintained. So our hero implementation of CD is great. But what is that after that? .

So the irony there We ready finish what we started. Because we've kind of got into a cadence where it's not important to finish what we started. It's always going to be that we've got placeholders.

So what can we do to fix this? Well for Pride driven development to get that pride out of the way. Language is definitely important and explaining ourselves If you read the domain driven design book by Eric Evans, he'll talk about that in the first few chapters around how language is very important between developer and subject, my tax, but all business analyst or business person. So talking the same language as each other is important. But similarly, I would say talking between developers as this is important as well. There is a kind of a unwritten hierarchy in development. Isn't there where we do use this kind of knowledge based approach , or this pride based approach to have you considered it this way.

And typically the one with the loudest voice or the one who knows the most or the one that's got the most experience can win it.

So what can we do to fix the situation with CD?

Here's a few suggestions I've been thinking about. One get pride out of the way. Treat your CD pipeline as you would your application. Debate its structure and architecture openly, but decide together so that you can build it and support it together.

Two: avoid heroes. Language is important. Ensure that you have a common language, which you discuss your CICD pipeline between developers and DevOps with. And actually understand how you can build it as another application in your organization.

One thing I really like is the approach that Brian Finster also mentions in a podcast. As Brian says, it's really up to you, the kind of organization that you want to be. I will link the No Nonsense podcast episode in the show notes, but I've also created a short summary post, which talks about the bits that Brian mentions around CD.

He is very passionate about his subject and very knowledgeable. And he goes off on the failings of organizations potentially around CD. And he talks about engineering for release, which I really love. This is the concept that you're building your release mechanism even before you've built the first line of code.

Building the pipeline before you've written a line of code.

Perhaps this approach to CD pipeline creation is something which is fundamental to success. Lots to think about. I've learnt and rewritten a whole lot during the recording of this episode. And I feel it still got a long way. I'd love to hear your opinions on this subject. too, and I'm looking forward to talking to you next time on the Software Delivery Club.

Thanks and good luck.