Ep. #18, DevOps 2.0

Edith Harbaugh: When I think of DevOps, I just think of the overall process of getting code from a box to production. DevOps 1.0 was just about making the pipe go smoother. This is where the original divide between dev and ops came from, is the developers would say, "Oh, we just built it, it's your job to deliver it."

Paul Biggar: The software that you're developing is a hypothesis that it will deliver value for the user. Whenever I talk to young companies, the only thing I say to them is you need to validate.

It might take you three months to get some software out. You would have to be lucky. I don't understand anymore how it could be done the other way.

Everyone says you should be doing, I don't know, 20 growth experiments a day or something, right?

Edith: No, twenty before breakfast.

Paul: Right, right.

Hi, I'm Paul Biggar, founder of CircleCI.

Edith: I'm Edith Harbaugh, CEO and co-founder at LaunchDarkly.

Paul: And you're listening to To Be Continuous, a podcast about continuous delivery and software development.

Edith: You can get in touch with us anytime at our Twitter handle, @ContinuousCast.

Paul: The show is brought to you by Heavybit. To learn more, visit heavybit.com. And while you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.

From 24-Hour Builds to DevOps 1.0

Edith: Hey Paul. So I've been talking to different people lately about DevOps 2.0.

Paul: Okay, well what's DevOps 2.0 exactly?

Edith: Well, and I have to preface, when I said DevOps 2.0, Jesse Robbins wrote me and he said, "I hate that term." So I knew I was onto something good already.

Paul: Right, right. If Jesse hates it, you might have something.

Edith: Yeah, I mean, I like Jesse, he's Heavybit too, but you know, I think a lot of DevOps 1.0 was just about making the pipe go smoother. And by the pipe I mean the release pipeline of getting bits from a developer's box out to production.

Paul: So smoother means less latency, or more predictable latency.

Edith: Less steps, more predictability, easier to do a build, like I was talking to...

Paul: Developers less annoyed.

Edith: Yeah, I was talking to the Microsoft folks, because we just did a big partnership with them, and they said the old days of Microsoft Windows, it would take twenty-four hours to do a build. Like, twenty-four hours.

Paul: You know, and like, so I worked at Mozilla, we had a similar lag. Same order magnitude.

Edith: Twenty-four hours?

Paul: I had a fifteen-hour one once. Oh, and it broke in the middle. It broke at 3 a.m. when I'd gone to bed.

Edith: Oh no.

Paul: And then when I woke up people had been yelling at me because the build had been broken for twelve hours. But yeah. It was a Saturday at 3 a.m.

Edith: It's a good thing you were asleep so you couldn't hear them.

Paul: Builds that go that long, release pipelines that go that long are inherently frustrating.

Edith: Yeah, they're very frustrating. And what happens then is you build up a culture around, "Hey, a build is gonna take twenty-four hours, so let's only build when we're very sure of things. We can't take any risks because if something happens halfway through..." Like, it's very defensive.

Paul: You end up optimizing around your own processes rather than removing all the accidental complexity of shipping software.

Edith: So I think the first wave of DevOps has been like making that process a lot smoother. So tools like Chef, Jesse's company, tools like CircleCI, Ansible have made it shorter and quicker to do builds. So now when people throw around 24 hours, people kind of laugh at you.

What I think has happened in a lot of organizations though is they still have all this institutional scar tissue from when a build did take a long time. And they haven't really changed a lot of their processes to take advantage of builds being cheap and easy.

Paul: Is this kind of like when people talk about doing agile, but really they're doing some sort of waterfall model with stand-up meetings?

Edith: Yeah, well there they do a stand-up meeting where everybody sits down. Which I've seen. You know, they have their hour stand-up every day where they all get into a room and sit down and talk.

Paul: I saw some company that changed its meeting to plank meetings. So whenever you're talking, you have to be in a plank.

Edith: Was this part of the interview process or like...

Paul: I think the idea is to shorten meetings because you can't really hold a plank for that long.

Edith: Yeah, I think my max, I don't even...

Paul: I think your max would probably outdo most people's max in the industry. It's generally a not very healthy industry. And you're an ultramarathon... What exactly do you do?

Edith: I run a hundred miles.

Paul: There we go.

Edith: But that's good for leg strength, not for arms.

Paul: Alright, well, your meetings will be short as well then.

Edith: Well, thank you for the compliment, and by the way, the LaunchDarkly shirt looks very attractive on you today.

DevOps 2.0 and Validation

Paul: Thank you, thank you. So DevOps 1.0 is shortening of this, or smoothening of the pipe. And so DevOps 2.0...

Edith: Is the realization that if we have a world where we could do a release in five minutes or ten minutes, how does that actually change how we approach how often we release? How does that change how departments within organization work together?

Paul: Gotcha, gotcha. It's probably no coincidence that my mind is screaming feature flags at this point.

Edith: Oh really?

Paul: Well, when you think about releasing software every five minutes, the thing that comes to mind is validation, that you're now able to validate things incredibly quickly. I've been talking to a bunch of people about how they do their CD processes, and sometimes people are like, "Well, you know, it's great, we'd love to be using CircleCI, but actually it takes us three months to release software and like, I would love to change that, but..." And I've gotten to the point where I just don't understand how to release software with three-month cycles anymore.

It's like whenever I talk to young companies, the only thing I say to them is you need to validate. You need to validate your business model. You need to validate that your products get to product market fit or minimal viable product and iterate your way there.

And so the idea that it might take you three months to get some software out, I just don't know how anyone can ever achieve validation. You would have to be lucky.

Edith: That's the whole idea of lean startup, is that you're taking more at bats.

Paul: Right, right. So I agree with it completely, and I guess what I'm saying is I don't understand anymore how it could be done the other way.

Edith: Well, are these three-month companies, are they young startups or are they more, you know, mid-level, mainline companies?

Paul: So there's a bit of both. A lot of the people I hear from are those larger companies where it's like, you know, "We're trying to change things around, we're trying to grow agile. There's a scrum master coming on board." And so they're trying to turn themselves around but don't really know what it means, and they're cargo culting it a little bit.

And then the other ones are startups that say like, "Oh, in six months we're gonna have a release, and it'll do this," and I'm just like, "What the fuck are you thinking?"

Edith: Yeah, you're either gonna be out of business, your competitors will have swam past you.

Paul: And it's the same sort of people who are like, "Oh, we're just gonna outsource this. We just need like thirty thousand dollars. We'll pay this outsourcing company and they'll deliver us the product." And it just blows my mind every single time. I don't even know the starting point to go back and explain to them how wrong they are.

Edith: Well, all right, so let's separate out the use cases. I think there's one, startups, and then there's two, main lines.

Paul: I mean, to me it's all validation. Like, it doesn't matter whether it's startup validation or it's like our next feature or what our customer needs validation. It's just all... You know, the software that you're developing is a hypothesis that it will deliver value for the user.

And sometimes you have a lot of confidence in your hypothesis, and a lot of times there you still end up being wrong. And a lot of times you're just kind of, you know, you think it's a good idea, but really you have no idea how much it's gonna get used.

Edith: I think there is a twist, that I think startups worry that nobody will use them. If you're an established company who already has customers, you worry that you'll break something existing. And that's where a lot of the fear comes from. So I'll give you a...

Why Feature Flags Lower Risk

Paul: Right, right. I mean, and here's why I get back to feature flags, because it lowers that risk. You can say, "I have this hypothesis that no one uses this feature."

I talked about this at the Web Summit. I don't think I mentioned it on the podcast, about how I broke Gmail in Firefox. Did I mention this on the podcast?

Edith: Did it involve a minion GIF?

Paul: So, oh my god, that's the greatest example of why you need continuous delivery. So like, imagine, like, they didn't validate that, right? They didn't do any bug validation. They just launched it on hundreds of... I guess a billion users now, without any validation at all, and like, there was two bugs that caused people to have the minion GIFs sent to their funeral homes and their bosses and their people who they're applying for jobs for, and very serious topics.

And maybe it's because it was that April Fool's thing that there wasn't an opportunity to continuously deliver it, or, I mean, they could probably have done something or slow rolled it around the world or something. But like, it is a key example to me of why continuous delivery lowers risk, and how not doing continuous delivery like Google did in that particular case is super, super risky.

Edith: Well, hold on, because they do do continuous delivery. They just didn't use a feature flag.

Paul: I mean, they may have done a feature flag, but they didn't slow roll it.

Edith: Yeah. So I think everybody agrees that Google uses continuous delivery.

Paul: Yeah, yeah, yeah, yeah. And I'm sure that was behind a feature flag.

Edith: You think it was?

Paul: Right, because they needed to, they were gonna delete it the next day.

Edith: Yeah, I don't know. I think it was just poorly executed. I think it's interesting that they thought they were funny and they weren't. And then they really had no way to recover very quickly from it because Google has such a big customer base. But I think that's separate then.

Paul: They could have found out that they weren't funny at a much smaller scale.

Edith: Much like me and my jokes.

Paul: Well, I mean, the fact that they didn't discover that they weren't funny within an hour or two of it launching, that it even hit the US market, or that it hit the billions of people. April 1st hits...

Edith: April 1st, every year.

Paul: Right. But it hits eight hours... Sixteen hours? Eight hours.

Minus nine. Minus nine is where it starts. That's where the first civilization is.

Edith: Oh, that's England. That's the Greenwich Mean Time.

Paul: So Greenwich Mean Time is at zero. We're minus eight from Greenwich Mean Time. So there's another four hours west of us, right?

Edith: Depends on daylight savings time.

Paul: So there's at least three hours west of us, and presumably they could have discovered... I know not very many people live in the area that's three miles west of us, but like, they could probably have discovered before it hit California, before it hit the US.

Edith: Australia.

Paul: Yes, yes, there we go. Australia is in...

Edith: Australia's actually a day ahead of us.

Paul: Where am I? Oh, I'm doing this wrong. Yeah, it goes the other direction.

Edith: Far be it from me to correct world expert Dr. Biggar.

Paul: No, no, you're right. It goes the other direction. So there's actually, before it hit the US, there was sixteen hours, it's minus five. So there's seventeen hours that they could have reverted this before it got to the US.

Edith: And they did it.

Paul: Right, right. They weren't reacting fast enough. They didn't have their metrics in place. They didn't have, I don't know what they didn't have. Like, I wasn't there, but like, that should never have hit the States.

I mean, it should never have gotten as far as the States. It probably shouldn't have reached Europe. I think it's a little unreasonable to expect three-hour turnaround time, but like five.

Five hours to realize, "This isn't going too well. Maybe we should roll it down to like ten percent. Maybe we should only show this to one percent of people while we figure out if they actually like it."

Edith: Or maybe we should just drop the mic entirely and leave the stage.

Paul: Right, right, right, right. Let's just delete this, drop the mic on ourselves.

Edith: Yeah, I mean, that's really a classic thing. I'm just surprised they didn't do it because it's very classic for companies to test new products in Australia. And the interesting thing is I went to Australia for work. Australian companies test new products in New Zealand. Because New Zealand is smaller than Australia, but it's kind of culturally...

Paul: Right, culturally similar.

Edith: Yeah, the same climate.

Paul: Interesting.

Edith: So they'll basically slow roll stuff out to New Zealand and see how it performs, then take it back to Australia.

Paul: Interesting.

Edith: New Zealand is actually pretty tiny.

Paul: So this is quite the diversion. Where did we start?

Expensive Builds and the Dev and Ops Divide

Edith: So I think you get these cultural practices around thinking that builds are expensive. So I've worked at some pretty mainline companies. And I worked for Vignette, which was a content management system, and the worst thing that we could do was to destroy a customer's data.

Like, anything else was like, "Okay, this is bad," but like, if we destroyed their data, it was really bad. You know, because this is like a newspaper and we're killing all their data. Cardinal sin.

So one time we did an upgrade. We released a new version of our software and during the upgrade routines it deleted people's content. Worst thing in the world to do. So what had happened is we'd shipped this out, and by shipping it out meant it was available for people to download, installed, and start installing. We realized pretty quickly that there was this critical bug because we had customers like screaming at us.

And so it was in this engineering meeting where the engineering director, instead of admitting fault and saying, like, "Hey, I'm really sorry that we did this," he started yelling at the operations director, saying, "Why does it take us so long to take a build down?"

Like, and I thought this was a total dick thing for the engineering director to do. I mean, at the time I thought it was, 'cause he just totally screwed up. He built this bad thing. And he was yelling at the operations director, "Why is it so hard to replace it with the new one?" And at the time, even though I was engineering, I thought the engineering guy was in the wrong. Now with hindsight...

Paul: Yeah, I'm not so sure about that one.

Edith: Now in hindsight I'm like, "You know what? It should be really easy to replace that."

Paul: So it should. I guess to play devil's advocate here. He... What's the engineer's name?

Edith: Let's call him Thomas.

Paul: Thomas. So Thomas knew the bands that he was working in. So he should have known it was a risky thing. Or he should have known that he couldn't roll it back. So that sort of bug would have been a disaster.

On the other hand, he's totally right, and if he had some sort of organizational mandate to push it forward, which I guess you almost de facto do, or to move your release processes forward, which I guess is de facto part of your job as engineering manager, then, yeah, that's quite defensible.

Edith: Yeah, and I think this is where the original divide between dev and ops came from, is the developers would say, "Oh, we just built it, it's your job to deliver it." And there just was a lot of mistrust and anger between them for precisely that reason.

Paul: Yeah, I mean, that's that divide between dev and ops, and you see it now that I think the expectation was, when DevOps was starting, that there was dev and ops and they were merging. And what I'm seeing instead is that they're not merging so much as ops is becoming DevOps. And then there's this separate sort of dev thing which builds new features, and DevOps is like keeping everything up, but in a more devy way than they used to.

I think there was an expectation that the developers would be their own ops people, which definitely some organizations have done, but is, I'm gonna say, not as prevalent as people expected it to be.

Edith: I think it all depends also, and I keep coming back to the stage of the organization. Like, I talk to a friend at a small startup and like, when you're three engineers, like, everybody is DevOps. But then you do, and then it's interesting, but then one of them is a little bit more opsies.

Paul: Right, right, right. Usually what you see is someone who sort of sysadmined in the late nineties, sysadmin stuff on the side while they're becoming a developer, and then sort of became the merge of the two and had a job title that included SRE.

Edith: Yeah. So I think DevOps is overall a good thing. I don't think anybody disagrees. There's been a change where instead of it being a throw it over the wall to next person and then a lot of finger pointing, now there's a much smoother pipe. With tools like CircleCI, which make it easy to turn around and build very quickly.

Paul: Well, so that's interesting, because that never felt to me like it was a DevOps tool.

Edith: Interesting.

Paul: So Chef felt like a DevOps tool, or at least that it was designed for ops people to maintain machines. Whereas CircleCI felt like a, "This is how software gets into production."

And in the small companies that used it, it was devs doing the whole thing, and there was some ops thing as part of their job. But as we started addressing much larger companies, there started being a lot more ops involvement, but it was still... So the developers were kind of the end user. Does that make sense?

Edith: Yeah, I think it's just when I think of DevOps, I just think of the overall process of getting code from a box to production.

Paul: So I think the distinction that I'm drawing is a lot less on what the actual parts of the job are and a lot more on people's identities and what communities they feel that they're part of.

Edith: Their tribe?

Paul: Right, no, exactly, their tribe. So there's developers, and even they, you know, tribalize quite a lot into Rubyists and Pythonistas and "I'm a front-end dev, I'm a back-end dev," whatever.

But the people who identified as ops in the past still regard themselves as kind of a different tribe than the DevOps. The people who were writing Perl scripts before are now people who are writing scripts to, you know, manage lots of Amazon instances, and sure, it's not Perl anymore, it's probably Python.

But there's a tribal identity of being former sysadmins, which I don't think is the same tribal identity as people who, let's say, did a computer science degree and became software developers, and, well, ignore the computer science degree, but became software developers and worked on products, and then those products became cloud enabled, and... You know what I mean?

Edith: Yeah, there's ivory tower, you know, computer scientists.

Paul: Yeah, yeah. Yeah, that's exactly what I'm discussing.

Edith: Yeah, Dr. Biggar, you wouldn't be familiar with that, would you?

Paul: No, no, no, no, no, not at all.

Marketing Meets Optimizely and A/B Tests

Edith: So when I think of it, I totally agree with you that there's different tribes. It was worth trying to describe the overall business transformation that happens at a higher level than just within developers and operations, but I think it's starting to spread to other parts of the organization like product and marketing, because like, they've been trained for... If you know you can only do a release every three months, that's a very different line of thought as a marketing person or as a product person.

Paul: One of the interesting things about the success of Optimizely... So Optimizely is an A/B testing tool, but it's an A/B testing tool that developers don't have to use. Developers install it once and then marketing can do instant upgrades.

And one of the things that it seemed, why this was so valuable and why it took off so much, is that it was targeted at marketing, who needed to make immediate changes. And who recognized the need for immediate changes, even though all the customers that they were targeting didn't have the ability to do immediate changes because they had longer release cycles.

So if you have a three-month release cycle, or even if you have a week-long release cycle, it takes you a week to get an A/B test out. Everyone says you should be doing 20 growth experiments a day or something, right?

Edith: No, twenty before breakfast.

Paul: Right, right. So maybe that's a bit aggressive, but certainly, you know, there's many order magnitudes difference between one a day and a week.

Edith: And I think also having been, so I was a really early beta tester of Optimizely at TripIt, it was that you got out of the hair of your engineering team, you know, because it used to be when I...

Paul: So I totally agree with that. The distinction that I'm trying to draw is when you had these older companies that had longer release cycles, I think Optimizely is evidence of how important that fast release cycle was for, let's say, the marketing department.

Edith: Absolutely.

Paul: Right. Or the product management team.

Edith: Yeah. But I think Optimizely has traditionally been used, I'd say, on front-end static websites and not backend.

Paul: Right. A/B testing is clearly a subset of feature flags. I didn't think that when they originally came out. I thought they had different purposes, but I've come to the conclusion over the last few years that it's just a pure subset.

Really, it's just a feature flag that's connected to a funnel, but every feature flag should be connected to a funnel.

Edith: Yeah, it's interesting. So one of the things I have found is I originally had this very engineering-centric world that everything should be measured, that, you know, everything should be A/B tested. And I found with LaunchDarkly, when I talked to more customers, that one, most people don't have the volume to do A/B tests. And like, if you're at Facebook scale, yes, you could do twenty experiments before breakfast. If you're not, you can't.

And second, this is really interesting, that a lot of times people just want to get qualitative feedback. You know, if you're a SaaS company and one of your biggest customers, say, is GE or Autodesk, you don't really want to A/B test on those users.

Paul: I think you might be using a different definition of A/B testing, because I certainly would be happy to turn on a feature flag for a customer like GE and say, "We have this cool new feature that you're happy to use."

Edith: That's exactly how people are using it, but they're not using it in the old blind way of like...

Paul: So the point of A/B testing, or one of the points of A/B testing, obviously there's the growth angle, but there's also the no regression angle.

Edith: Absolutely.

Paul: So we're making a change to this. And we think this change is going to be neutral at best. But we're doing it because I'd know better positioning, better support, something in the market that we're not measuring in our funnel, and we're doing it differently. And we expect that it's just completely neutral and it won't tank our metrics. But that knowledge that you're not going to tank the metrics, that's super, super important to go out there.

And so you slow roll it, and you see that you even, they don't have to be particularly statistically significant.

Edith: That's exactly it.

Paul: We get 10 users a day signing up, and 10 users a day continue to sign up, great. I don't need a thousand people to do this.

And so I guess the reason that I tied feature flags and A/B tests together is, to me, A/B tests, or it used to be that I thought that A/B tests were hooked up to business metrics and feature flags were largely turned on to operational metrics. But really they should be both.

Releasing to Innovators First

Edith: I keep coming back to DevOps 2.0. I think that's the change that we could start to make, is that suddenly you could tell your marketing person, "Well, hey, you know, we could just launch this feature in New Zealand very easily." Very cheaply.

Paul: I love the example that Facebook talked about once, where it's like, we can launch this feature to one percent of women who are twenty-five to thirty-five in the Bay Area who have expressed an interest in... I think this was some sort of wedding-related thing that they were talking about. And it's like, wow, that is a very, very niche thing that you can target and experiment on.

Edith: Yeah. The way I frame it is that you can map your releases to crossing the chasm.

Paul: Oh, that's a really nice way of thinking about it. So you release first to the innovators. Then early adopters, and so are you dividing your user base into like laggards and an early majority and that sort of thing?

Edith: Yeah. I mean, a lot of the friction that used to happen as a product manager in engineering was this pressure of, "Something has to be right because it's gonna go to everybody." And then there's always, you know, this old-line customer like Merck. You know, or Morgan Stanley. It's like, "Oh, it needs to be bulletproof because it's going to Morgan Stanley." And then at the other end you have your nimbler people who are like, "I just want this release now. Like, I'm fine with it being buggy." In fact, that's great, because the earlier your innovators want to get involved.

Paul: It really bugs me when I talk to startups who have the idea that they need to get it perfect for the launch. And it's like, how will you know if it's perfect if no one has seen it? Like, it will never hit twenty thousand or twenty million or whatever people off the launch if it hasn't first seen 200 people who say they love it.

Edith: Yeah. And there's this paralyzing fear.

Actually, Michael Dearing gave me really good advice. I felt like in the early cycles of LaunchDarkly that we weren't doing a very good job at onboarding. And he's like, "That's fine. More people will come." You know, 'cause he's like, "Work on your onboarding. See the next people go through, collect the metrics." And it was like a very reassuring pat because...

Paul: And in fact the same people will come again.

Edith: Yeah. Michael Dearing is a super smart guy.

So the way I look at feature flags is not so much just A/B testing, but more it's very freeing for organization to decouple, to decouple the marketing launch, to decouple perfection, and start to segment their users and say, "Early adopters get this now."

Iterate. Innovators get it. And then when it's all bulletproof, which might be, depending on the feature, might be two hours later, might be two months...

Paul: Someone was talking to me about how some of the teams at Heroku did releases. And what they said is that they have a one-week-long sprint where they design the feature on Monday and they get the first version out Wednesday morning. And then they get a lot of feedback from internal users, and then they get the second version out Wednesday evening, or Wednesday afternoon or whatever. And then there's a final launch on Friday.

And it's like, that was their entire development process. And so like, they get an entire feature out in five days, but also that there's like two to three rounds of iteration within that process of launching that feature.

Edith: Yeah, I mean, so at LaunchDarkly itself we use LaunchDarkly on LaunchDarkly.

Paul: I would expect so.

Edith: So depending on the feature, we could have much longer with it just within our early beta users. You know, if it's something like, so we just did custom roles, which was a high-end feature for enterprise customers where you can get really granular control over who can control a feature flag. And in the turtles world, we control it with a feature flag.

Paul: Of course. I'm vaguely getting it, but that's a little complicated.

Edith: Even today when I was on a sales call, like, we had an early customer who's like, "Can I get the access to this? It's okay if it's a little not fully documented or a little rough."

Paul: Yeah, as long as people understand that they're getting something half-baked. And in fact, you always want to have someone who understands that they're getting something half-baked, because you never know how to bake it. You never know quite what temperature it needs to be cooked at.

Edith: Hopefully you even have a mixing bowl in an oven.

Paul: Right.

Edith: So I was talking, I keep coming back to the curve, and what's interesting also is that the curve for a feature is different.

For different features, somebody might be an innovator on one feature and a laggard on another. So it's not a set thing that one group always wants all early features.

Sometimes there could be some features that some people want that others don't.

Feature Flag Debt

Paul: Right. I think the important thing is to make sure that people always get the feature in the end. You don't want too many people who have the feature turned off a long time out. Like, I'm sure you have customers who are suffering from feature flag debt.

So is it the same thing as technical debt? There's code paths that you can't release because there are still customers using both sides of the feature flag?

Edith: No, we haven't had that. But we're pretty vigilant.

Paul: So I'm sure your customers will have it. If not your own feature flags, but your customers' feature flags. Facebook had, I think at one point they did an audit, they had four thousand feature flags that still existed. Many were years old and just, someone hadn't seen it to the end.

Edith: Yeah. I mean, so the worst example I heard, well, there's probably worse, was, so we went to Microsoft Build and I presented, and then a ton of people came to our booth to tell us their feature flag stories. Which was awesome, because a lot of people had built their own homebrew and they're like, "Of course, here's what we face."

So this is hilarious. They're using feature flags and they had an ambiguously named feature flag that two separate teams started using for completely separate things. And they didn't have a nice system, they just had it in a config file somewhere. So what would happen is basically, like, one team would start amping it up, and their team would like be using it for something else.

And it was like the classic thing where like, it's like, "It's not working right. Like, let's turn the knob up, you know, let's turn the knob up further." And it just like was completely messing up all their software.

Paul: That's hilarious.

Edith: It's basically when you think of your yaw as your pitch or vice versa when you're flying a drone.

Paul: So what's our takeaway from all this?

Edith: Well, my biggest takeaway is I think DevOps has made it easier to do builds, and I think people are still catching up with what that means for an organization.

Paul: Yeah, there'll be a lot more things in the future that are based on that idea, that deploys are cheap now.

Edith: That deploys are cheap, that you don't have to push everything to everybody at the same time. And then that frees up a lot what you can be doing with your software.

Paul: Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Biggar of CircleCI, and Edith Harbaugh of LaunchDarkly.

Edith: To learn more about Heavybit, visit heavybit.com. While you're there, check out their library, home to great educational talks from other developer company founders and industry leaders.