Anders Wallgren on Giving Software Development a Seat at the Table

Brian Dawson: Hello everybody. Welcome to this episode of DevOps Radio. I'm Brian Dawson and I'll be your host. Joining me today is Anders Wallgren, former CTO of Electric Cloud and current VP of Technology Strategy at CloudBees. If you're wondering why I mention two titles, it's because if you haven't heard, on April 18 we made an announcement that CloudBees acquired Electric Cloud, which is a big movement in our industry and hopefully has a really strong and positive impact in that it brings together the leading CI/CD solution with Jenkins and CloudBees and the leading continuous delivery and application release automation solution with Electric Cloud. So, today we'll talk a bit about the acquisition, but then more importantly we'll talk about the state of continuous delivery, application release automation, and DevOps, and what the joining of these two organizations means for the industry. Anders, hello. How are you doing today?

Anders Wallgren: I'm doing very well. I'm happy to be here, Brian.

Brian: Awesome. Awesome. I've been looking forward to speaking with you. So, before we get started, while many of our listeners know who you are, just in case, can you tell us a little bit about your background?

Anders: Yeah, my background is mostly technical. I have been a software engineer fairly continuously since for the last 30 years. I've definitely managed teams, been VP of engineering, chief technology officer, those kinds of things. But I've always, and this is really a compulsion for me in terms of I can't not do it, but I've always had my hand in the technology, if not at an architectural level then even at the code level, at the implementation level, always being pretty close to that. That's one of those things where that's just how I operate; that's how I think. I find I need to understand the details of how a machine works before I can sort of take it apart, put it back together and maybe make it better in the end.

Brian: And I assume that's both a blessing and a curse?

Anders: Yeah, it is. It is. I mean, that is a nice edge to walk in terms of you definitely don't want to be so much in the weeds with the technology that you can't see the big picture, but at the same time if you don't understand the technology...I think understanding the technology allows us to make better decisions, and allows us, I think, also to be a little bit closer to the actual process of how these things are created and maintained and all of those kinds of things. And it really I feel it makes me more relevant in terms of guiding the technical future of the products that I work on.

Brian: Yeah, absolutely. I would agree with that. And that is probably part of the recipe of the success that you and your colleagues found at Electric Cloud. You guys securely established yourself as leaders in application release automation and the newly sort of developed segment of continuous delivery and application release automation, or ARA. We'll get into ARA and CDRA in a minute, but before we do maybe you can tell me a little bit about the history of Electric Cloud and what problem you guys were solving that led you to securing that position of being a leader in that space?

Anders: Electric Cloud is, we're kind of a teenager as far as a kind of a startup goes. We were founded in 2002. The original product, and one of the two products in our portfolio still, but the one that got the company started was Electric Accelerator. To simply it for the nerd audience, is basically a parallel distributed Make that gives you a correct and very fast build every time. So it's build acceleration, build and test acceleration. It's a fantastic product. I mean, it is catnip to people who sit around waiting for hours for builds and now they can wait for minutes instead of hours and that's a really big thing. But the interesting thing about that is that once that was out in the market one of the things that we immediately kind of got as feedback from a lot of our customers was "Great, you've helped me take my 10-hour build and made it an hour, or taken a three-hour build and made it 10 minutes, so my engineers don't have to go to lunch or go home while they wait for builds. They can actually keep building and stay in the flow, as it were."

But guess what? There's a lot of other stuff that has to happen to our software before it makes it out the door, other than just build, compile build, and link it. We've got to test it. We've got to run code coverage. We've got to do regression analysis. We've got to do performance testing. We've got to do security scans. We've got to do all these other things as well. And right now, going back about 10 years if not a little bit more, we're doing all those things manually. We're managing the process on Post-It Notes and in Excel spreadsheets. And not to knock Post-It Notes and Excel spreadsheets, but they are kind of the lowest form of process management, as far as I'm concerned. So, what we started working on was Electric Flow. And the idea there was basically to provide a way for our customers to be able to orchestrate and manage and get visibility into and analyze all of their processes. So, from all the way from in our case, from code commit all the way through to where the code is available for the customer, whether that means deployed to a website or burned into firmware or available as a mobile app in the App Store or the Play Store, those kinds of things. And to really take a very broad view of solving that problem. And of course, the space is application release automation or orchestration, analysts you talk to for CDRA, CDRO. But a lot of the processes are still very manual. And one of the kind of philosophical bents that we've always had is we don't want you to have to completely uproot and change your process just to make it better. We've always had this kind of idea of, "Look, we are an orchestration tool, we are an automation tool, but we're going to incorporate and track and manage your manual processes as well, whether they be you have six weeks of manual testing at the end of every release, God forbid." But that still happens quite a bit. Or we have manual approval processes where we have CABs that we have to go through in order to get changes approved and those types of things. And really, just put some automation and some measurement and analytics around that so that even if you have very manual steps and processes that we start to track those. And the kinds of customers that we're dealing with are typically large enterprises, large organizations, so they have multiple of everything: multiple locations, multiple applications, dozens, hundreds, thousands, sometimes tens of thousands of applications and components and systems that have to be managed. So, all of this had to be done at scale as well. And so, our approach to this has really been, "Look, we're not interested in coming in and telling you that you have to change everything that we're doing. In other words, we're not gonna jump in your car while we're driving down the freeway and insist that we change all the tires on the car and swap out the engine while we're still driving down the freeway. Also recognizing that we can't pull over for six months and retool everything because that doesn't work." It's very much been about, "Hey, let's discover what it is what you do today. If you want, kind of do a value stream mapping or analysis on how your code goes from commit to what the path to production is. And then, get an idea for where we want to do some automation and orchestration, get an idea for where we just want to track the manual processes, and then give you and reflect back, if nothing else, the analytics on what happens." And now you can start to think in terms of, "Where are the errors being introduced? Where are the cycle times being expanded beyond where we want them to?" And kind of get an idea for, "Hey, if I've got 50 products in my portfolio, I'm not necessarily going to set off a Big Bang effort to say, 'Oh, make them all better.'" Right? Because those kinds of efforts generally go down in flames pretty significantly. But instead, kind of take an agile approach if you will, do your DevOps or CD transformation, right? So think about where are your pain points are today? What's the next boulder that we need to blow up? And then blow that one up, whether that's through automation or through some analytics or through changing the processes or what have you, and then move on to the next one. And really, kind of live on that continuous improvement mantra of it's not the quality of the daily work that matters as much as the improvement of the quality in the daily work. And really, what Electric Flow is, in addition to environment management and process management and artifact management and all of these kinds of cool things, it is also an environment in which you can get a handle on how you're getting your products out the door at scale and then start to work on improving those processes and decide where to put your resources to make those improvements.

Brian: All right. Yeah, there's a comment that I have on that that I think is really interesting is this recognition that software is business-critical and it's not within everybody's ability to stop a project and completely retool it to get that ideal, what I'll risk calling ideal delivery or continuous delivery pipeline right now. But rather you guys have taken an approach to figuring out how to empower all application teams, in particular, traditional application teams, to get them on the way to that ideal pipeline without disrupting their business. Something that I've noticed in having a conversation with you and the Electric Cloud team is that you guys have really made your mark in going to release managers in what we traditionally call right-hand-side operation teams and saying, "Hey, look, the left-hand-side is starting to move fast and there's a risk that they're moving faster than you and overwhelming you, so let's get you tooled up to automate and manage your processes in synchronization with the left-hand development." And I know I won't reduce it to just that model, but that's where I've seen a place where there's a lot of power because then you are in a position where, as you say, to be able to then iteratively improve on top of that until you eventually reach the ideal. Right?

Anders: You're really hit the nail on the head there. Really, part of this is, look, agile was tremendously successful. But agile and I know the manifesto talks about delivering software to the customer, but, so that's always been in there, but the practical application of agile in my mind and in the minds of a lot of people was it had an impact on development teams, on QA teams, and on product ownership, product management. And really helped bring together better processes there and more efficiency and greater throughput. Then the problem is kind of plumbing that last mile out and that's really where DevOps comes into play a little bit. That idea that we have to figure out how to work at velocity without breaking things with all due respect to the "move fast and break things" people in the world. You don't want to break your bank account. You don't want to break your shuttle launch. There are certain things that are not good to break. Whether my Facebook comment feed is up to date or five minutes out of date, not a big deal, right? So break that all you want. What it kind of comes down to is, and I actually have this is a visual I'm going to describe, which I know is a terrible thing to do on radio. But I have a slide I use in one of my presentations, which is really just a little video snippet from the old black-and-white I Love Lucy show, where Lucy and Ethel are working in the candy factory and the candies are coming down the conveyor belt so fast that they can't package them fast enough and so they start eating them and stuffing them in their clothing and throwing them away and all this sort of stuff. And that in some sense, I think, mirrors a little bit the experience that kind of moving from left to right that QA and release management and operations and so on had as engineering teams started to shovel more and more code out the door, vastly simplifying what's happened in the last 10 or 15 years. But really, part of the problem, part of the challenge is plumbing that last mile. We've had customers who had gotten their agile processes into a good enough state to where they could take a bug report from a customer, identify and solve the problem and get it built, tested, qualified in under an hour. And that's from the time that the customer calls. And then, it would take them 90 days to put it into production because their process for putting it into production was still, and I don't want to throw ITSM, ITL, change approval boards, and those kinds of things under the bus completely, because there is value in a lot of what they do, but there was a lot of process that you had to go through. And of course, during that 90 days, you're now accruing lots of other changes as well. So, now you're stepping away from that sort of lubed aspect of small batch sizes and...

Brian: You don't get the value that you get of the feedback loop, right? If it's sitting on...if the chocolates are sitting on a shelf before they make it in a box and ship to the customer, to do a bad extension of the analogy...

Anders: Exactly.

Brian: Right?

Anders: No, that's a great extension.

Brian: We don't know if they like the coconut-filled chocolate or not, which hinders our ability to do better. I'm going to use this to transition in a minute, but you brought up an interesting thing. You don't want to throw ITSM under the bus. When we talk right-hand delivery, there is a real and valid slant towards ensuring quality, stability, and uptime, protecting the customer. And you know what? Dev, there's a real justification for wanting to fix things fast. But it's really about, and I think what you guys had achieved, is bringing those two together and getting them to operate on the same cadence so you can really have the best of both worlds.

Anders: Absolutely. And I think for anyone who's followed the State of DevOps Report, the Accelerate State of DevOps Report, that Dr. Nicole Forsgren and Jez Humble and Gene Kim and the folks at DORA, now part of Google, have done over the years, the data strongly suggests that when you do this, when you adopt DevOps for, if I'm going to pick one umbrella term, when you adopt DevOps you get to do the stuff better and at speed. And that leads to happier customers, happier shareholders, happier employees, all of those kinds of things. And so, you can move fast and can't break things. Now that requires change and change is difficult. It may require cultural changes. It may require HR-type organizational changes. We're definitely seeing now, I think in the data, especially anecdotally, but also in some of the research that it also means aligning more around product and less around projects. Now if you're a product company already, you kind of have a leg up on that, but for a lot of IT organizations, they're very project-based. And that's a difficult kind of cadence to have and then also service a customer at the end of that. We're seeing a lot of organizations kind of adopt the "product, not project" mentality as part of that.

Brian: So, you actually you introduced DevOps in your answer there and you set me up well. I wanted to ask, we live in an industry of three-letter acronyms, right? We've already mentioned CD, ARA, ARL and other TLAs. For our audience, I'm not sure everybody knows what ARA is. I have a 22-year-old CS student who now understands continuous integration and a bit of continuous delivery but probably doesn't understand what ARA is. Can you explain to her and the rest of our audience one, what ARA is, and how ARA fits within the DevOps movement?

Anders: Tthe textual definition of ARA, application release automation, or as Gartner prefers to call it now, application release orchestration, it's really about looking at the value stream and finding the places where we have manual handoffs, where we have manual tasks and starting to tighten those up and starting to automate them to the greatest degree possible. Now if at some point you need to have somebody look at a web page to make sure that it looks right, then you need a pair of eyes. We're not quite there yet with doing those kinds of things. So it's not necessarily taking the human out of the loop. But it is absolutely, I would say, philosophically taking the human out of the loop for things that humans are no good at or that we're wasting our time to use humans to do it. I'll give you a very concrete example. Some change management boards, part of what they'll meet to do is to look and see, for example, "Do we have the right code coverage?" Well, that's not something you need to get a bunch of people in a room to do; that is a simple numeric comparison. So, as long as you have your code coverage automatically generated, then you already have all the information that you need in order to do what would in Electric Flow be called an exit gate or exit criteria, to exit one stage and enter into another, to just look at it and not even bother people to have a meeting unless you've already exceeded or met that criteria or requested an exception for it. So, I think there's a lot of kind of rote theater that's involved in a lot. A change advisory board does not add security. A change advisory board,  and I'm not picking on them, and there's lot of other words for these things, but they don't add quality. All they can do is try to prevent problems. And oftentimes, the way that they end up preventing problems is by slowing things down. And we've seen that that doesn't necessarily work as well as we think it does. Most of the time it really just slows you down. And you can look at a lot of the security incidents that have happened over the past few years and see that all of those companies were implementing pretty strict change controls and that did not prevent these problems. So, the problems are a little bit deeper. I'm rat holing a little bit on security there.

Brian: Yeah, go ahead. Go ahead. So, it's a little bit deeper.

Anders: But the encompassing here is, look, what are all the things that, what's the value that you want to add to your code before it goes out the door. Right? What are all the boxes that have to be checked and all of the double checking and triple checking that we need to do to make sure that when we push the big button, whether it's pushed literally or whether it's done automatically, and something goes live for the customer that it's not going to blow up in our face? There's a lot of mechanisms and processes and procedures that we can bring to bear on that. We can do canary deployments. We can do blue-green releases. We can do early access programs. We can do all kinds of things to give us confidence in that when we do the final big release and expose all of this to all of our customers that it's gonna work. Different organizations take a different approach to that. What we've always tried to do is just work with the customer to figure out what are the things that they need to do? What are the pain points? So, you need to do blue-green deployments? Here's a mechanism for doing that. You need to do canary deployments? Here's a mechanism for doing that. You just need to automate your pipelines so that, yes, we're doing CI and unit testing automatically but we need to also do integration testing and system testing and performance testing and security scans and penetration testing and all of the things. A lot of those things are still islands of manual stuff, or at best islands of automation. I've had many experiences where somebody will tell me, "Oh, yeah, our testing is completely automated." What they really mean by that is, "Once I've submitted a ticket to have an environment provision and that ticket is manually serviced by someone in the IT organization and then they manually tell me after they get back from lunch or from vacation or from being sick, that they've done that, then I can go submit my next request, which is to get a particular version of that application installed in that environment and the same thing happens. Once all of those things have happened, yes, then I can do my automation testing." But to me, that's islands of automation and we're still just in another kind of siloed kind of environment. And we take a much broader view of this and say, "Look, if it can be automated and done in a single pipeline, it should be." There's data that every single manual handoff introduces delays. Every manual handoff introduces the potential for errors. Every time you have a manual task, a manual deployment, a manual configuration, that's where errors are introduced. I mean, computers are not perfect but they will do the same thing over and over and over if you ask them to.

Brian: Right, if you ask them in the right way. I'm gonna take you in the land of fuzziness and I'm counting on you, Anders, to add absolute clarity for the rest of us here. All right?

Anders: All right. Challenge accepted.

Brian: All right. So, I'm a developer. I've implemented Jenkins. I've been working with Jenkins for years. I started out automatically building and integrating my code. That worked; that was awesome. I then extended that into this world of another three-letter acronym that we call CD. I've started using Selenium to crawl my site and validate it. I've used Gatling to do some penetration testing. And at the end of that, I've ended up with a binary that I can deploy. I do CI/CD. Why do I need this ARA thing? What is this ARA thing? What are you bringing to me? So, I guess the fuzziness is there seems to be some confusion and probably particularly from developers as to, "Look, I'm doing this. It's CI/CD. I'm done. Hands brushed. Let's go." Can you tell me where CD and ARA meet?

Anders: Yep. So, I think one of the ways that I would put this is and sorry, developers and I am one myself, so I'm speaking to myself but you want the real world, the beginning, middle, and end of.... So, to give you an example, one of our very large customers, a financial institution, when they push out new code, so if they're pushing out, say a new module that calculates commissions differently on, I don't know, insurance policies or something like that. Pushing out the code is only one tiny little piece of what has to happen as part of this. You also have to make sure that you are educating your customers as to what's coming and what the differences are, and that requires coordination. So, a lot of the things around ARA that are incremental to what you would just kind of call CD and kind of leave it at that are the externalities of the real world. So, have we got training materials? Have we trained the people? Or are the training materials available? Have they been debugged? And so on. So, I'm picking a very kind of simple, obvious example here of something which is very not software-centric at all, it probably used software, training software, those kinds of things. But this has nothing to do with what the developer is doing. So, the developer looks at their little piece of the elephant and says, "I'm done. I've written the code, I've written my unit tests, and I've submitted. What else do you need to know?" Well, it turns out there's a lot you need to know, and especially if you're in a regulated environment, right? You may need to have lots of extra steps that happen before that stuff can go out the door. But in general, there are a lot of activities that the business has to do.

Brian: Right.

Anders: And hopefully, all of these value streams kind of start and end with the customer, but the business is in there. The business has decided "We're gonna make a change." I'm not talking here about sort of patching and security and those things. Those, I think, those can live at the development, at the technical layer. But when we're dealing with at least in terms of execution. But when we're dealing with something that the business is trying to accomplish, well, you have some sort of go-to-market for that. So, you've got some sort of marketing that you're doing, some sort of announcements and splashes and tours and trade shows and all the things that have to happen for that. As well as in the beginning just kind of deciding what it is that we want to build. So it really, I think all of these things are around the acknowledgment that technology and the business both have to have a seat at the table, as Mark Schwartz's book is called, A Seat at the Table, and that business and IT and technology have to work together to solve the customer's problems. And that the business alone can't solve it, obviously, but neither and just as obviously to me, can IT and technology solve it. That's is as much of a vacuum to solve it in as would be the business just trying to solve it. So, it is an acknowledgment that there are nontechnical processes that are involved in these things and coordination and concerns that have to be met that may not have anything to do with the Python code that the developer just submitted.

Brian: Right. Right. So, "commit to binary" is just a part of the picture. If we want to go from concept to customer, we need a more holistic view, an automation solution like what CDRA provides. Is that correct?

Anders: Absolutely. Absolutely. And also, if you're thinking about it in terms of maybe I'm also re-architecting these applications. So I have new services that are popping up and APIs that need to be maintained and infrastructure that needs to be..maybe it's on-premise now and we're moving it into the cloud, or maybe it's in the cloud as VMs and we want to move it to containers or even to more sort of serverless architectures. There are a lot of forces that a business and the technical component of that business have to worry about and have to think about. And we've seen how disruptive software can be to existing business models. Think about musicians. There's tons of, think about retail.

Brian: I'm gonna jump in on that because now I get a question that fits well and I get a shift to acquisition. So, we've talked about CDRA, the recognition that software development doesn't live in a silo but it needs to have a seat at the table with the business together, and I think that's a good setup for this acquisition. So, CloudBees has acquired Electric Cloud. They're now working together. I'm going to ask you why are Electric Cloud and CloudBees good together? And what do you think it means for the industry at large?

Anders: I think there are a lot of very complementary things. I mean, when we started this process probably almost a year ago, we sat down and kind of made a list of, "Okay, who are the companies that we'd like to work with on this?" And CloudBees was on there for sure. But we also kind of looked at it and went, "Hmm, not sure how we can make that work." But then, Sacha called, the CEO of CloudBees, for those of you who don't know, and kind of the rest is history. We managed to figure out a way for that to work. And I think what's interesting about it is, I think we have played Electric Cloud in the enterprise space very, very heavily. We are solving some of the really tricky, gnarly, kind of technical and scale problems that our customers have. Customers that need to do, they need to have 10,000 team members on the same system at the same time, or they need to push through 100,000 builds or deploys a day against tens of thousands of endpoints and those kinds of things. But it's been a very, and I'll just be blunt about it, a very commercial enterprise. Very much a sell software with less, and I'll just be blunt here, with less focus on kind of building a community around this. We have been very involved in the DevOps community. I mean, we co-founded the DevOps Enterprise Summit with Gene Kim and his company, IT Revolution. And we're very proud of that, and that's grown hugely. It's one of the premier, if not the premier conference out there for enterprises doing DevOps.

Brian: Yeah, it absolutely is. Yeah.

Anders: But where CloudBees for me is coming in, I don't want to sort of pigeonhole this down too much, but there's a hell of a community around CloudBees. A hell of a community around Jenkins. Whereas we're dealing very often with not the individual contributors, clearly Jenkins, CloudBees are dealing very often with the individual contributors. I think there's a lot of complementarity there in terms of the audiences that we work with. Because in some sense, one of the sayings that we've had for years here at Electric Cloud was if we were competing with CloudBees about anything, one of us was in the wrong room, because we either were going after something that was very CI, kind of CD-centric, and not ARA, ARO or CDRA kind of centric. And so, I think there's a huge complementarity here between the technologies, between the customer bases, between the communities. To me, this is definitely one of those things where one plus one will end up equaling more than two once we get a chance to put the pieces together.

Brian: Awesome. Awesome.  And so, then, shifting from there, you've had a lot of experience in the CI/CD/ARA software development and delivery space, as exemplified, I think, by your involvement and Electric Cloud's involvement with … and Gene Kim. I think everybody knows who Gene Kim is, but just to state that he is really one of the luminaries in the DevOps and improvement movement, as is the DevOps Enterprise Summit. So, that leads me to want to ask you, where do you see the current state of CI/CD in DevOps? How has it changed in recent years? And what do we see coming on the horizon?

Anders: I think the major way that it's changed in say the last two to three years, because if I roll the clock back to, say, 2016, 2015, maybe even a little bit before, when I went out and talked to a prospect or talked to a group of people, invariably I would spend the first half of the meeting just explaining what DevOps was or what CI/CD was in many cases. What it was, who it was for, why it was good. Why you couldn't buy it in a box. "If I could sell you this stuff in a box, I would, but look, this is gonna take cultural changes, process changes, as well as obviously tooling changes and tooling support." But in the last, since that time, since about 2016 on, the market has become educated to a much greater extent. And so, these days, it's really not, the first question is not, "What the hell is this and why do I care?" The first question is, "Where do I start?" Invariably. I mean, whether I'm giving a talk at a conference or giving sort of a lunch-and-learn at a company or something like that, almost always the first question is, "Where do I start? How do I get started on this? What's important?" Those kinds of things. A lot of things go into that obviously. All the conferences from DevOps days to ... to CloudBees days and all of these things have played an important part in that. But I think also what's played an important part in that is seeing companies succeed with DevOps and with CDRA and with CI/CD and actually make a difference to the success of these companies. And as I mentioned before, the State of DevOps Report put out by DORA is a great source of data if you need to go, if you need to go hit somebody over the head with data, that's a great piece of data to do it with because it's very rigorously analyzed and has several years' worth of data now in terms of really showing and demonstrating the impact that this can have on the success that companies have. And that is a difference. So, that to me is the major difference, not having to explain what I do for a living for the first 15 minutes or first 30 minutes of every meeting. And it's really, then, a question of, "How are you different from your competitor? Should we worry about this? Should we worry about that?" And of course, "Where do we start?" And to me, that's great because now it's, "Okay, let's dig into it. Where are your pain points? How do you do this? How do you do that?" And that to me is much more exciting and much more rewarding in every sense of the word than kind of just having to once again explain what CI/CD and DevOps is and why you should care.    

Brian: So, you brought up a really interesting point that I want to get into. So, I think sometimes you and I and many of us in this space get caught up in an echo chamber and not to lay blame at your feet, Anders, but where it feels like everybody gets this and everybody should be getting it. But when you look at some of the surveys and we ask, "How many people are practicing DevOps?" or even when we look at DORA and we see who's actually implementing things to kind of exist in the high performer/elite performer space, we end up finding out that there are still a number of people that are trying to figure this out.

Anders: Absolutely.

Brian: And as you said, a question that you're emerging is not the what or why, but now it's the how. So, I know there's no simple answer but I want to continue to challenge you and see if you could give us kind of a succinct, easy-to-digest answer to, "How do I get started? What do I need to look out for? What do I need to do?"

Anders: So, I think to give kind of a generic answer to that generic situation, it's really about understanding who your customers are, what they want and building product teams around that. There's a great book that came out recently by Mik Kersten, the CEO and founder of Tasktop, called I think it's called Project to Product, talking a lot about these kinds of transformations and how to align them around customer and product and around the flow of that value, and making sure that teams are aligned around the value stream, basically. And so, one of the first things when a customer or a prospect or a random person on the street comes up and says, "Hey, how do we do this?" It's really about, "Understand how you're doing it today." That's really how you have to start. The goofy analogy I give is if you and I are doing a road trip and we decide we're gonna go from San Francisco to Chicago and we get halfway there when we realize, "No, we don't actually want to go to Chicago. We really need to go to Dallas." If we don't know where we are at that point, we can't change our route. And I know that's a really goofy analogy, but where a lot of especially large organizations are today is that they don't understand their value stream. They really don't have that sort of map of how does, and I'll refer back to, and this is very temporally and culturally limiting, but there used to be these Saturday morning cartoons called Schoolhouse Rock, and one of my favorites was, How a bill becomes a law. It follows the personified bill through the whole process and so on. What a lot of us need to do is put a GoPro camera on the head of our source code and follow it through the process and see what actually happens to it so that we understand how much time is wasted, how much opportunity is wasted, and how many mistakes we make on the way out the door. And that begins with understanding what you do today. And it's amazing when you get the right set of people in the room to talk about and to draw out on the whiteboard or the white sheets of paper or the Post-It Notes or what have you kind of, "Hey, here's how we do our work" and the amount of epiphanies that you see on an ongoing basis in those activities around, "Oh, I didn't realize we did that at all" or "No, no, no, we don't do it that way at all" or "We stopped doing it that way." No factory in the world, whether it's a car factory or just any other sort of manufacturing activity would stay in business unless they understood really well their supply chain, their assembly line, all of those things. And yet, in the software industry as a whole – I'll condemn all of us – we don't understand that worth a damn. We are really, really bad at doing that and we need to get better at doing it. Without that understanding, we can't increase our velocity. Without being able to increase our velocity we can't compete. Without being able to increase our velocity we can't respond quickly to security kind of vulnerabilities which, that's going to be a big thing and it's only going to get bigger as time goes on and more and more kind of life-critical activities end up online. And obviously, a lot of them, most of them already have. We need to get better as an industry.  And this, the current state of the art in getting better is DevOps. That, I think it's the undisputed champion. And something else may come along in the future. It's not the end of history for sure. But that is the current state of the art in terms of how you do that stuff now.

Brian: I'll put my opinion in. I think, yes, something else will come along. We'll be focused on something else in the future. The name will go away. But I think the collaborative approach that we are driving into the veins of software development and delivery through DevOps is something that will live and need to live, as you call out. There's power to talking and understanding across and eventually without some of the silos that exist today amongst our teams and from project to product. So, thank you for that. So, I want to ask, I want to try a couple of new things with you, Anders. Are you familiar with something called "drunk history"?

Anders: I've heard the term a few times in the last couple of works and I'm not, I have yet to investigate it. But it sounds like fun.

Brian: Okay. So, we're not gonna do drunk history today. All right? What drunk history is, to explain quickly, is people drink a bunch of alcohol, they get on camera, and they tell a historical, funny story. What I want to do for our listeners is we oftentimes talk about the ideal world of how you get started, the ideal situation in software development. But I also think there's a lot of value in sharing the failures, the funny stories, the things that didn't quite go right. So, you're gonna be the first person to participate, alcohol-free, in what we call "trunk history." And so, what I'd like to hear from you is for you to share a story with us of a funny moment in your career, in software development, whether it be in general or whether it be implementing DevOps, which would also be something we call "DevOops." But if you could share a bit of your trunk history with us.

Anders: You know, it's funny. I'm going to use this as an opportunity to sort of slam on one of my pet peeves.

Brian: Okay. Have at it.

Anders: Which is not management by objectives per se, but management by ship date. I think management by ship date has been one of the most corrosive ways to manage software projects that I can think of, that somehow the most important feature of a piece of software is the day it ships. Now, unless you're TurboTax with a little bit of a fixed deadline or you're a gaming company and you want to make all your revenue during Black Friday or so on, then whether you ship on day X or day X plus 10, I think that's been one of the most kind of corrosive influences on software quality that I've seen. Now, I have to temper that, right? Because you can't let the perfect be the enemy of the good. And I'm not actually suggesting that we ship later. I'm actually suggesting that we ship sooner and more often and more frequently, and of course, get the feedback loop going as much as possible. And I think that's really, that really gets back to where, I mean, that's what continuous delivery wants to be, right? Agile and continuous...

Brian: Now, can you tell, can you share with me an incident where having what I'll rephrase as date-based development impacted you and the way you work or has come back to bite you?

Anders: I can think of a couple of times in our past. I'll get a little bit specific here. We did a giant re-architecture of our database schema, not giant, but significant many, many versions back, probably about five years ago, in support of the clustering horizontal scalability that we were introducing. And I think we vastly underestimated the length of time it would take to upgrade our customers' data. And I think that was a thing where had we gotten something out more quickly and to some customers instead of waiting until we had something ready for customers, we probably would have learned that lesson a little bit quicker and not then been left kind of scrambling, quite frankly, to come up with kind of background updates and a lot of the kind of stuff that we had to build to make that better. So, I think it's one of those things where we were all driving to a date and we wanted to have everything ready and everything had to be. Everybody had to be in the boat before the boat could leave the dock. And I think an approach that would have worked better in that sort of scenario was to,  is to do something simple, like, "Hey, why don't we do the schema translation as a separate release and do nothing but that, and not try to pile on a bunch of functionality as part of doing that?" Now, in our defense, a lot of our customers are and have been historically have been on-premise customers because there are still a lot of organizations out there that are not, they may be doing a lot of things in cloud, but a lot of their infrastructure and a lot of their critical processes still happen inside the firewall, and so we've had to operate in that environment. But that's something I look back on not once a week anymore but at least once a month in terms of,"Man, we could have just – we could have done that a lot better if we had broken it up into smaller chunks, into smaller batch sizes." I think going back, can I think of a way that we could have done that realistically? Actually, I don't. But it really just hammers home the lesson that when you try to do these Big Bang releases and try to get everybody in the same boat leaving at the same time you are definitely holding yourself beholden to whatever the long pole intent is. That's not good for anyone. It's not good for the team. It's not good for the functionality because you don't get the feedback until much later in the process and so on. I think my big learning from there, quite frankly is, "God, I wish we don't have to do on-premise software ever again." That won't be for quite a while yet. But SaaS is obviously where it's at from the point of view of doing those kinds of things in little experiments and do things quickly and so on.

Brian: Well, awesome. Thank you for sharing that with us. We'll give a try, you are now the inaugural trunk history/DevOops interviewee or guest. So, another thing I'd like to ask before we move to your final thoughts are I heard you reference a number of book titles as you were talking that are really compelling. I wrote down some notes; I'm going to read some of those myself. If you have one recommended reading for our audience right now, what would that be?

Anders: I would say if you have not read Gene Kim's The Phoenix Project, go read that. It's great. It kind of lays out in a very personable, easy-to-read way kind of all the different aspects of, a lot of different aspects that we've talked about here. And Gene also has a new book that I don't know if it's out yet, but it's about to be out, and not that I'm shilling for Gene, but he just happens to be a great writer on these things. But he's got a new one coming out called The Unicorn Project, which kind of follows up on that quite a bit. And those are great books. If you want to just get a ... The Phoenix Project especially, if you just want to get kind of the zeitgeist of what DevOps is and the kinds of problems that it solves, the personalities that are in that story are the personalities that we all work with good, bad, and indifferent. And that's a very valuable thing. I would definitely recommend both of those. One is out; one, I think, is about to be out.

Brian: Okay. Awesome. Yeah, and I think if it's not out, The Unicorn Project is at least available for pre-order on Amazon. So, thank you for that. So, Anders, it's been a joy. Before we wrap, I'd just like to give you an opportunity to share any final thoughts, recommendations, guidance, predictions, what have you, with our audience.

Anders: Speaking just sort of from a very selfish perspective, we're happy to be joined up with the CloudBees team. I think we're already starting to meld the teams together and start to work and plan and figure out kind of a bunch of new cool stuff that's coming out there. But we're also going to work a lot with the community and with the customers to figure out where the pain points are and which arrow we should put most of our effort behind and do that. Stay tuned. We'll definitely be out there talking to the community and talking with customers to figure out what's next, as well as we have a lot of great ideas already, of course.

Brian: Awesome, Anders. Thank you. And I will say I am personally looking forward to it as both an employee of CloudBees, but not only that, also a member of the community and a practitioner. I think there's going to be some really cool things happening. So, everybody, thank you for joining for this episode of DevOps Radio. And we look forward to having you join us on the next episode. Thank you, Anders.

Anders: Thank you.

Like what you’ve heard today? Don’t miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz follow CloudBees on Twitter, Facebook, and LinkedIn.