devopsy.kinsta.cloud

Tag: podcast

  • To Be Continuous Podcast: Have We Forgotten How To Code?

    To Be Continuous Podcast: Have We Forgotten How To Code?

    Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly.

    In this episode, Paul and Edith discuss the fallout after the widely covered “left-pad” incident, and while they agree that these sorts of moments move the entire open source community forward, they wonder: Have we forgotten how to code?

    [soundcloud url=”https://api.soundcloud.com/tracks/264605904?secret_token=s-Kv9Ep” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Edith: Hey, Paul. So, somebody unpublished a module called left-pad and the internet basically exploded. And now it’s been a couple weeks since then, so there’s a lot of different topics to cover in terms of what this means for open source, whether it means that people have forgotten how to program.

    Paul: So LaunchDarkly. Or, I’m sorry, the left-pad. I’m obviously looking at my own t-shirt.

    Edith: You’re looking at your LaunchDarkly t-shirt?

    Paul: The left-pad incident was pretty interesting and one of the things that we did when coming up to this was just, like, looking at all the Hacker News discussions and comments on it.

    And there’s wildly varying positions on what this means for open source, what it means for whether people can program, what it means for, like, about the Node ecosystem. So to kick this off, why don’t you give us a recap of the entire incident?

    Edith: Yeah. So, in short, a programmer had a module called Kik, K-I-K. Which is also [the name of] a very popular messaging app. I mean, even I’ve heard of it and I’m not a teenager.

    Paul: The Kik lawyers contacted the dude. Said, “Please take down your module, change it.” And the programmer said, “No. I basically don’t believe in copyright laws.” So then, the Kik people contacted NPM. The NPM people took down the module called Kik. And the guy, in I’d say, kind of a fit of pique, said, “Okay, you took down my one module, I’m gonna take down all my modules.” Basically, I’m taking my marbles and going home.

    So, he took down all of his modules. One of which turned out to be an incredibly popular module called left-pad, which did basically what the name implied. It sorted left pads. And without this in NPM, the quote I read was, “Builds all over the world started to fail very quickly.”

    Paul: So as I understand it, left-pad was used by another module, which was used by another module, which was used by something core, or like, this incredibly popular module—

    Edith: Yeah, it was basically turtles on top of turtles on top of turtles, and at the bottom turtle was this guy who—

    Paul: Took his marbles and went home.

    Edith: Yeah, or yank the bottom Jenga, basically.

    Paul: Gotcha. And so all the builds started to fail. People’s deploy started to fail. And people got pissed.

    Edith: People got pissed because they didn’t even realize that they had this dependency. So what happened was NPM basically republished it. They said that, even though you’re the original publisher—

    Paul: So there was a lot of outcry on the internet and then they republished it.

    Edith: Just basically said, “You don’t have the right to un-publish this.”

    Paul: Gotcha. So, um, but they had an Unpublish button, as I understand it. So he did something that was built into NPM to remove a module.

    Edith: Yeah, and since then they have tightened their rules a lot. They basically said that this should be something that’s used extremely rarely, if at all, and not something you can just do capriciously.

    Paul: So one thing that’s interesting about the NPM ecosystem, and the Node ecosystem in general, is they’ve had a bunch of things like this. Things that are security-related, or that are drama-related.

    And people have repeatedly come out and say, “Oh, no, JS is a tar pit, or ghetto,” or whatever it is that people use to describe poor ecosystems, that normal programmers don’t know how to code, and so on, so on.

    And what it looks to me like is, you know, each of these incidences brings the Node ecosystem quite a bit forward. To the point that, I mean Node is relatively new, it hasn’t had 15 years before prime time in the way that Ruby or Python did, or 20 years before it got big, and it’s a real, kind of bottom-up thing.

    I mean, if someone built it and there were some steroids and then someone else took over, and then NPM took over, and then. It’s this sort of weird language from the ecosystem perspective. It didn’t have the same advantages that, like, Java had, or that C or C++ had, in order to get to maturity. And so each of these incidences propels it closer to maturity.

    Edith: Yeah, I compare it somewhat to when electricity first started coming out. And then you were just working through all the issues that could happen. Like, for example, when a power line went down or a transformer blew.

    Like, you work through, Okay, what are our points of failure? Let’s not make that a point of failure again.

    Paul: Hmm. So, NPM changed their policies on this basis, right?

    Edith: Yep, so now you can’t have an individual contributor be able to unpublish, even if they originally published. Now you have to contact them, and it’s much more stringent.

    Paul: Gotcha. The response, despite people being … Well, people were annoyed at their response.

    Edith: It seems perfectly rational to me.

    Paul: Oh, I think it seems perfectly rational. This is the thing about the in trend. There’s always some set of people who are annoyed at everything you do.

    Edith: Well you know, the internet is full of billions of people. I mean, there’s gotta be some sort of standard deviation, or otherwise it would be a very boring internet.

    Paul: Right, right, and this is why there’s always haters on Hacker News. No matter what you do. If you do it one way, there’ll be one group of haters, if you do it another way, there’ll be a different group of haters.

    And so, with left-pad, there were people who were annoyed that NPM retroactively decided that they had ownership over their namespace, which previously, they had sort of gifted to people in the community, the first people to take the namespace.

    Edith: You mean the original thing about Kik?

    Paul: So there’s that, but there’s also the left-pad. They took away the sort of autonomy of the left-pad offer.

    Edith: I read a good article that basically says part of open source is, if it truly is open source, do you maintain the rights to it? Or is it a community project?

    Paul: Hmm. The traditional way of deciding that sort of ownership was the fork. That you could go, and you could fork, and when you forked, you weren’t necessarily entitled to the same name, you weren’t entitled to the same trademarks. When Debian forked Firefox, they called it Iceweasel.

    When Jenkins was forked, or Hudson was forked, it became Jenkins. GCC got forked. They all got new names. But what was the fork here, it wasn’t even a fork. It was a republish of the same thing, the same software, in a namespace that the original author didn’t control.

    So typically you’d own the URL, you know, if you have a software library, you’d own the URL. And they did own, in some sense, the URL within NPM, or the name within NPM’s space, and NPM, the sort of owners of that namespace, overrode it.

    Edith: I think they did what was necessary for good order.

    Paul: Sure. I completely agree, I think that was a good decision.

    Edith: I mean, so to take this to the logical conclusion, what if you had a module named left-pad, and you decided that, like, as a prank you were going rewrite it to be right-pad? Like, sure, that’s … Is that within your rights? Kind of, but it’s a real jerk thing to do that you probably want to prevent.

    Paul: This is kind of one of the dangers of the whole ecosystem around centralized package managers, of sorta trusted package managers, where there’s no actual trust involved. So, what I mean by that is what is published does not have any gatekeepers.

    Edith: Yeah, exactly.

    Paul: I mean, it’s great, it allows an ecosystem to grow much faster, but it has safety concerns because people generally don’t pin their packages to an exact version.

    Edith: You’re basically pinning it to a floating value.

    Paul: You’re pinning it to a floating value. And that floating value could change. There’s no guarantee of what a minor number means or what a major number means or what a patch number means or what a patch even means. There’s some sort of, like, general community guidelines in semantic versioning, but there’s no enforcement of that.

    Edith: Yeah, and I mean this basically goes back to the whole Cathedral versus Bazaar thing.

    Paul: Right, right. It’s very Bazaar. And intentionally so. It’s the thing that allows a community to grow, and is there a point at which open source communities need to, like, batten down the hatches to prevent that sort of behavior? Or prevent that sort of risk?

    Edith: Yeah, and it’s really interesting. I think this goes back to something we’ve talked about with Nadia Eghbal and Sean Byrnes a couple episodes ago about when you buy from a corporation, you have some sort of guarantee of standards that they publish somewhere. You know, this is our guarantees versus with open source, you don’t normally have those same sort of guarantees.

    Paul: Even when you do, it tends to be—

    Edith: There’s no enforcement mechanism.

    Paul: Right. So there’s no enforcement mechanism in the Bazaar.

    Edith: Well, there’s no, um … Like, so with a company, if a company has said, “Okay, we’re gonna release twice a year and it’s gonna have this level of quality,” and they break that, you can walk with your feet or your money. If an open source project stops or does something that you don’t like, there’s very little enforcement end.

    Paul: Theoretically, you could walk. You know, you could fork the thing, but when you end up in an ecosystem that has massive network effects, and in the way that NPM does, you can’t walk with it. Because the pends is all transitive. The left-pad was, you know, a turtle way at the bottom of the stack.

    Edith: It was almost like a turtle hatchling.

    Paul: So, to fork left-pad, you would have to fork the entire NPM ecosystem.

    Edith: Yeah, and it’s not even. The fork is not the issue, though. The issue was that people were depending on it being in a certain place in a certain way. It wasn’t that it wasn’t forked, it was just like this entire structure at the bottom was gone.

    Paul: I guess what I’m saying is that if you get pissed off with a certain set of developers or a certain set of practices within the NPM community, because they’re so interlinked, you don’t have the traditional open source option of forking.

    Edith: Absolutely. Absolutely.

    Paul: You could rename it. You could pick a different library, but because of the way—I’m not sure if they still do this, ’cause I read something about it, but in NPM, it used to be that the version of the software that your library took was the version that library got. Do you know what I mean by that, okay. So let’s say there’s some software, let’s call it left-pad.

    Edith: Let’s call it right-pad.

    Paul: Right-pad. So, right-pad version one is being used by library A. And right-pad version two is being used by library B. In the Java ecosystem, and many, many other ecosystems, only one version of right-pad would be used.

    And I believe in NPM, both versions of right-pad would be used. So library A will use version one, and library B will use version two. Now that’s definitely the way that it used to be, I’m not sure if they’ve actually changed that.

    Edith: Yeah, I don’t know, but that sounds very messy, very quickly.

    Paul: So both options are terrible. And there isn’t a right way to do it.

    So, really, what it depends on. So, the NPM way of doing it, every library get its own version of the dependencies, is fantastic. Because it lets that library do what it actually intended to do under the covers.

    If, however, you start having an object that gets sent around, or that two modules are, let’s say it receives a, I think, an HTTP packet or something like that would be a good example. Let’s say you take an HTTP packet from one module and just hand it to another module, and they have different understandings of the shape of that object, or what functions you can run on that object, then that’s messy.

    But, on the other hand, if you override the version of right-pad that some other library’s using, you end up with all sorts of problems. This is a major problem in the, sort of the Maven ecosystem. And at CircleCI, we used Clojure, and Clojure is built on top of the Maven ecosystem, and we would have bugs where the library that we used.

    One library that we used had a dependency, and that was in the package file for another thing. And so, that’s the version of the packets that we used. So we would have to pick. And as a result of that, we have to pick the library that works. And, often, there isn’t a library that works for both, or there isn’t a, sort of subdependency that worked for both. So those are close to forked no matter which way you do it.

    Edith: Yeah, I mean, we ran into the same issues with our STKs. I mean, ’cause we have dependencies on other libraries that sometimes conflict.

    Paul: Right, disaster.

    Edith: On the other hand, I mean, the bigger point, I think, was. So there was an interesting backlash, I think, that everybody kinda projected what they wanted on the NPM thing.

    People said, Oh, people don’t know how to program anymore. You know, why do you even use what they called left-pad? You know, why don’t you just grind your own wheat and make your own bread from scratch and eat it at lunch also?

    Paul: I have no sympathy at all for this view of the world.

    Edith: Uh, that you should make everything from scratch? Or—

    Paul: That, “Oh, we’ve forgotten how to program because we need left-pad.”

    Edith: Yeah. The fact that we have modules available that make it easier and easier and easier to program is a good thing.

    Paul: I think it’s kinda different to that. I think it’s more of a curmudgeon view of the world. It’s a get-off-my-lawn—

    Edith: Wait, that you’re the curmudgeon?

    Paul: No, the people who complain, “Have we forgotten to program anymore?” I think it’s a no true Scotsman kind of argument. Real programmers know how to write their own left-pad, real programmers write in statically typed languages, real programmers write in C, real programmers, and I’m going back in time here, real programmers write in Assembly, real programmers hand-code their. Tweak the needles on the.

    Edith: They do their own garbage collection.

    Paul: Oh, and it’s garbage collection, what is this? Garbage collection is for amateur coders, right? I mean, you could just as easily have written, have we forgotten how to manually allocate memory?

    Edith: Or, you might as well say, like, nobody knows how to make their own transistors anymore. I mean, like, the entire computing revolution has been that you no longer have to assemble a computer by hand.

    Paul: Right. And each layer of the ecosystem allows a vastly larger number of people to take part in it. So I think the thing that we’re seeing now. This has been happening for five or 10 years, but what’s getting really, really big now is people who only know how to front-type program.

    People who only know Javascript and HTML/CSS, and they go to boot camps and they come out, they maybe have some, like, vague real understanding.

    And they call themselves coders, and we, the real programmers, who know how to write a quick sort, and who know how to write left-pad, we don’t welcome them to our community. And frankly, I mean, I have felt this in the past, I have since changed my mind, but it’s a very, very common perspective.

    This podcast is brought to you by Heavybit, a program that helps startups turn products loved by developers into successful businesses. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

  • DevOps Chat: Nathen Harvey, Chef

    DevOps Chat: Nathen Harvey, Chef

    I recently had the pleasure of catching up with Nathen Harvey of Chef. And I do mean catch up. As VP of community development, Nathen keeps up an amazing pace of visiting Chef communities around the world. In this role who better to understand what DevOps practitioners are seeing? Nathen and I spoke about several things including Chef’s security and compliance capabilities.  Below is the streaming audio of our conversation and below that is a transcript of our discussion to follow along.

    Enjoy!

    Alan Shimel:                Hi. This is Alan Shimel for another DevOps Chat here on devopsy.kinsta.cloud. Today’s guest is Nathen Harvey, VP of Community Development at Chef. Hi, Nathen. How are you?

    Nathen Harvey:           Great, Alan. How are you doing today?

    Alan Shimel:                Good. Nathen, I’m going to bet that most of our audience already knows who Nathen Harvey is and what your role is at Chef, but maybe for the few who are unfamiliar, why don’t you give our audience a little bit about what it is you do as a VP of Community Development at Chef?

    Nathen Harvey:           Yeah. I get asked that question a lot, Alan, and I’ll tell you that the real definition is this. There are two parts to it. The first being VP of Community Development means that none of my code runs in production and that makes the world a much safer place, if we’re being honest.

    Alan Shimel:                Okay.

    Nathen Harvey:           The second thing is before I joined Chef I did actually have code that ran in production. I actually managed a bunch of production infrastructure. So when I moved from an operations role into a community management role, the thing I like to say about that is I put down the pager and I picked up the bar tab. Oddly though, I’m up at 3:00 AM either way.

    Alan Shimel:                Yeah. Well, I think that’s just part of today’s work environment, where everyone is up it seems at 3:00 AM, depending where you are in the world.

    Nathen Harvey:           But joking aside, it’s really about going out and meeting with our community and helping fuel the love of Chef, helping folks in companies large and small get better at automation, get better at dev-ops, get better at great software development and infrastructure practices.

    Alan Shimel:                Yeah. And, Nathen, you’re not kidding about seeing people the world over, too, as part of your role, because I follow you on Twitter, I follow where Nathen is speaking, and whether it be a local meet-up group or a Chef users’ group or a conference or customers, you literally are traveling the world constantly.

    Nathen Harvey:           Yes indeed.

    Alan Shimel:                Yes, preaching the Chef message. Nathen, I wanted to focus our talk a little bit today around one of my favorite subjects, security, infosec, whatever you want to call it. Chef has become one of the leaders and has been for some time – one of the leaders in security within the dev-ops movement, if you will.

    I had the pleasure of becoming friends with Justin Arbuckle a year, year and a half ago. Justin was out preaching – what was it – compliance at Velocity or something? I may be mistaken.

    Nathen Harvey:           That’s right, compliance at Velocity. You bet.

    Alan Shimel:                You know, for a long time and it resonated with me. Then of course I think Chef made an acquisition, a European company who sort of had a compliance vulnerability scanning for code.

    Nathen Harvey:           Yes.

    Alan Shimel:                And now you guys have really kind of laid down the gauntlet on this and really put the pedal to the metal in talking about why it’s important to do this and why it’s important to do it earlier. I don’t want to steal your thunder. Can you give our audience a little bit of your opinion on why it’s important and what should be done?

    Nathen Harvey:           Yeah, sure. Look, Alan, in a traditional way of developing our software we all fall under some sort of regulatory burdens. We all have auditors or other security controls that we need to make sure are implemented within our production systems, and the traditional way of doing that, at one point in your development workflow you might introduce a security scan into the development workflow itself before you go to production, but usually that ends up just being a blocker for moving flow, moving change across your organization.

    So you’ll oftentimes pull that security scan out and then just start scanning your production systems. But for me, scanning the production system is kind of like the oil light on your dashboard. When it comes on, it’s too late. You have to have solved that before you get into the production environment.

    So at Chef, really we look at our roots with automation and our ability to fully customize and fully automate the buildup and the maintenance, configuration management of your infrastructure over time, your infrastructure and your applications. We say that we need to make sure that we’re always in compliance, but it’s also very important for us that we start to adopt more of the development workflow, more of the software engineering principles.

    One of those principles of course is that we should do test-driven development. Well, why not take those controls and those audit controls that you have to enforce and move those directly into the development workflow? You certainly see many cases where you’re doing, say, static code analysis during your continuous delivery pipeline or during your continuous integration. But what about moving that even further back and doing not only static analysis of your code, but also actually testing what does the running application actually look like? Is it exposing ports that it shouldn’t? Is your infrastructure configured properly? And can you do that on the developers’ workstations, move that -? We like to say you’re moving compliance to the left. If you think about your change flows from left to right, from your developer’s workstation all the way out to production, how do we get and start thinking not about how to scan the production environment better, but instead how to start making those controls into your developer’s workflow?

    Alan Shimel:                Yep. Nathen, as a security person that’s almost radical to me. I will tell you, having spoken to many security people about this, we actually put on a DevSecOps day, a Rugged DevOps day at the RSA conference last year in San Francisco and Justin spoke there. A lot of security people, this makes them very nervous, believe it or not, Nathen, because it’s not them doing the scan. We’re going to ask developers to scan their code on their workstation, while I’m not there to see it, right, or not there to make sure that the code is right?

    Nathen Harvey:           Right, right.

    Alan Shimel:                Go ahead. I’m sorry.

    Nathen Harvey:           Let’s look at that. In the past, and I understand where these security folks are coming from, but if we look at today’s enterprise and the way that software is built today, security folks want to be the ones that are doing all of the scans, that want to be the ones that are making all of those assessments. On the one hand that’s fine. They should absolutely be involved in those assessments. But, frankly, if it’s the security team only that’s responsible for that, it’s simply not going to get done. The security teams aren’t big enough; don’t have enough capacity to keep up with the rate of change. They’re going to become a blocker in the enterprise and that’s going to become a real problem.

    So it’s really that security professional’s goal or the way that they need to look at this is, first, automation makes their job much, much easier. Not only can we remediate things that are found much, much faster, but we also gain consistency and things like that.

    But if we can then partner with the development team, with the engineers that are building out those systems and get them to think of security as a first level concern and compliance as a first level concern and start being partners with us, like we’re partnering with them, we’re not abdicating our responsibility to them. Frankly, some of the scans that the security team is going to run in the production environment, they’re still going to run those, but what we’re going to find by giving developers better tools to run those scans sooner, to ensure compliance earlier in the process, that those scans are going to find fewer and fewer vulnerabilities, and those vulnerabilities that are found we’re going to be able to address and remediate much, much faster.

    Alan Shimel:                And I might add, Nathen, not only much, much faster, but much, much cheaper. I mean I’ve seen studies where it’s something like 10x to 100x cheaper to take care of a vulnerability or a compliance issue at that shifted left stage, where it’s still on the developer’s workstation rather than on some cloud instance. Right?

    Nathen Harvey:           Absolutely. That may feel radical, but it’s really just we’re going back to our roots. I mean we’ve known for decades that fixing a bug in the development process is much less expensive than fixing it after that bug has been released into your production environment. The same is true for a security control or a compliance control.

    Alan Shimel:                I agree. I agree with you. Nathen, I have another issue I wanted to touch on with you, and that is some people get hung up on the compliance, the C word, so compliance versus security. They’re not synonymous, right?

    Nathen Harvey:           They are not. They are not at all synonymous, no. I think that compliance – Alan, let’s think about this. You have a CEO at a company who has to sign off and agree to – have auditors come in and assess whether or not they are compliant. Frankly, when an auditor walks in the building, there are many, many organizations who say, “Our number one objective when the compliance person walks in, when the auditor walks in is to get them to sign off on our audit and leave as quickly as possible. I don’t want them meddling in my business. I want to get them out of here.”

    Alan Shimel:                Yep.

    Nathen Harvey:           So with that approach, what we really do is try to make sure that we can run compliant systems, and compliance is there so that we can assess whether or not we are secure, but security really needs to – it’s a different mindset than compliance. Compliance sometimes is the easier place to start. I want to make sure that my audits are passing. When I have audits that are passing, I can sleep at night knowing that my audits are going to pass. Then I can start to look broader at the system in terms of: am I actually building a secure system? But, frankly, security is the foundation and compliance is what sits on top of that.

    Alan Shimel:                Yes, absolutely. Nathen, the other thing I think that really has enabled – and maybe it’s a little bit of a chicken or an egg kind of issue – does this enable them or they have enabled the compliance issue? Developers are taking to heart the fact that security is everyone’s responsibility, and the fact of the matter is it starts with them. Right?

    Nathen Harvey:           Absolutely. Alan, we’ve seen similar things in the past. Look at QA teams, where developers have said, “You know what? We’re going to start doing test-driven development. We’re going to adopt some of those practices.” And the QA teams get nervous, “That’s my job.” The problem with having it be someone else’s job is you’re not going to do it. You’re not going to be concerned with it.

    So, really, just like our QA professionals are now partnering with the devs, the security professionals and compliance officers are now partnering with the development teams. Frankly, that’s what dev-ops is all about. It’s about this working together towards those common goals and getting there as quickly as we can.

    Alan Shimel:                Yeah, absolutely. And it’s good. It’s good on so many levels to have the security team integrated with the devs, to be working closely with both dev and ops, dev-ops, and making it happen because, frankly, that’s what attracted me to dev-ops to begin with, was the promise of being able to do that instead of being the appendage at the end of the Rube Goldberg kind of –

    Nathen Harvey:           Absolutely. Alan, what you’re really looking at there is we’re talking about a partnership. So there are some cultural or some workflow changes, some partnering that we have to do across the organization. The thing that helps enable that also is the tooling. The tooling definitely matters and the two, culture and tooling, are there to reinforce one another.

    So with Chef, we have a new open source language called InSpec and that’s the tooling that allows the developers to actually write these compliance controls, execute them locally. Frankly, it allows them to write them in a way that’s delightful, in a way that a developer understands, that a business analyst can look at those tasks and understand exactly what’s happening.

    Then with Chef compliance we also introduce those same compliance controls into our own scanner capability, where you can scan against your production environment, find vulnerabilities, go back into your automation code, remediate those, and watch that remediation happen across the entirety of your pipeline.

    Alan Shimel:                Fantastic. Nathen, as I had told you earlier, before we started recording, our time is limited, but for folks who maybe want to find out more about compliance scanning, more about Chef’s capabilities in this area, where can they go to get more?

    Nathen Harvey:           For sure the place that they can go is www.chef.io/compliance. Again, I just want to stress that the scanning capabilities are absolutely important, but really what we need to do is shift our mindset and think about: how do we start writing tests for those controls and do those early on in the process? Not that scanning should be an afterthought, but we really do need to focus on that beginning stages of our development process.

    Alan Shimel:                And automation, automating that is key. Nathen, we’re almost out of time here. Unfortunately, it always goes too quickly. But I wanted to ask you one last question, which we usually ask our guests here on DevOps Chat. That is one book, if you had to recommend one book to our listeners that they should read maybe over the summer or in the near future, what book would that be?

    Nathen Harvey:           I would recommend Lean Enterprise: How High Performance Organizations Innovate at Scale. It’s a book by Jez Humble, Joanne Molesky, and Barry O’Reilly.

    Alan Shimel:                It’s actually on my bookshelf. Cool. I love it when someone suggests a book I’ve read actually. Very cool, Nathen, and it is a great book. Jez’ Lean Enterprise book is great as of course is the Continuous Delivery book.

    Anyway, Nathen, we’re about out of time here. So I wanted to thank you for being our guest on DevOps Chat. Continued success with your globetrotting VP of Community Development role at Chef, and continued success to Chef in general there. It’s one of our favorite companies in dev-ops and we love what they’re doing.

    Nathen Harvey:           All right.

    Alan Shimel:                And maybe we’ll get you back on again soon.

    Nathen Harvey:           Yeah, that sounds great. Thanks so much, Alan.

    Alan Shimel:    Okay. This is Alan Shimel with Nathen Harvey, VP Community Development of Chef for DevOps Chat. Thanks and we’ll see you next time.

  • Don’t Make Me Code Podcast: Onboarding Developers

    Don’t Make Me Code Podcast: Onboarding Developers

    Thanks for listening to Don’t Make Me Code, a podcast that discusses developer experience design and the unique challenges of building developer-facing products. Don’t Make Me Code is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

    In this episode of Don’t Make Me Code, Steve and David talk about some of the challenges of onboarding developers, and ways to make that experience better.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/245152401?secret_token=s-4SUlM” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Steve: So, today we’re talking about onboarding, and what a pain it is for developer tool companies. It’s weird to me that, in the consumer world, we’ve got products that we can happily onboard into in seconds, and in the dev tools world, we go in the range of minutes, you know, five or 10 minutes feels pretty good.

    David: Yeah, we’re dealing with like, complicated things that people are integrating into these other complicated things that they’ve built, and it’s often not quite as simple as ‘just type in your email address and click a button.’ You know, you have to add some pieces to your code, or add some dependencies, or start instrumenting things—there’s all this stuff you might have to do to get started.

    Steve: And those requirements feel just unreasonable at times, I mean I can’t stand going through it, having to write code to onboard into a product.

    I remember getting stopped using New Relic for the first time, and having to actually write code before I could start using the product, and it’s discouraging, but required. And it’s just this infinite frustration and we, in our product, we’re trying to eliminate that as much as we possibly can, but, it’s a unique frustration of our world.

    David: Definitely, I mean, we’re trying to deploy applications to the Internet and they can be, you know, the variation to those is so huge, and so we spend a lot of time focusing on making it work out of the box without you having to make a whole bunch of changes right out of the gate. I think that’s really important.

    Steve: See, you and I are both at early-stage companies, we’re dealing with our Beta customers now, and that’s a very high-touch scenario, we’re interacting with them very closely and one at a time. But, we often have to deal with things like personal email addresses, where they’re signing up for the product as a company, but using their personal email, so, I spend about 10 or 15 minutes just discovering who the person I’m dealing with even is.

    David: Yeah, I mean, we definitely see that a lot, and it’s actually not just personal email addresses, you know, they’re actually probably trying us out in the context of personal accounts to begin with, or personal, you know, maybe they’re coming to bring a personal project like their blog, or something like that, to begin with, and they want to like, ‘Yeah, is this thing going to work, before I actually start to try and introduce this at work?’

    Steve: Yeah, and you’re trying to demonstrate value in an environment that, one, is not the intended environment, and two, might have totally different requirements around it. And, you know, for us at Amazon for example, we’re dealing with people’s personal accounts that have things like EC2 Classic support, which has been deprecated, and their production environments at work are a lot less likely to have that, but it’s something that we, as the makers of the product, have to consider just because of how people might onboard into it.

    David: Yeah, definitely.

    Steve: And even if we’re lucky enough to get somebody’s work email address, we still have to go through the whole test flow, where they put us in their staging environment, and give us a try. And it’s a tough constraint to be in a place where you’re going to have measurably less value, but still have to prove that you can be valuable to the customer.

    David: Yeah, they want to see, is this tool going to work for me.

    No matter how good your documentation, no matter how good your examples, most people are going to want to actually put their hands on it, and see how it works, and see where it falls down. And any experimentation is sort of like the name of the game for our target customers.

    So I think providing some sort of backdraft for that, and making it really easy to play with your product is pretty important.

    Steve: Yeah, and really considering how you’re going to provide value in these circumstances where you might be restricted is super important. Although, I have to say, this morning, we had a guy sign up for the product, put us in an environment that had literally nothing in it. It was an AWS environment with 0 instances and 0 groups, and we’re a product that health checks other things in the environment, and there was nothing to health check. That was a tough sell.

    David: Now he knows that you’re not going to take down his Amazon account, I guess.

    Steve: Yeah, and that too, the security check, right, like, half of the battle is convincing people that, one, you’re not going to break, two, you’re not going to break their stuff.

    David: Yeah, I think, and that’s certainly another driver for why people try with their personal accounts first, right? It’s like, ‘I’m not going to install this tool into my production account at work that I don’t know anything about.’

    Steve: Yeah, it’s been really funny actually to watch this, ’cause we do a lot of onboards in person over video chat, or even just watching their laptop screens, and we’re dealing with incredibly smart people. They watch, and they can see what our onboarding process is doing to their environment, and they go and audit everything, they’re checking every change to preferences, and they know exactly what’s happening. And they check us on everything, which is, you know, worrying, but also kind of cool to see just how good they are at what they’re doing.

    David: We basically, we get the same thing, people trying to install us into their actual Amazon account, it’s a pretty tough sell, we’ve had a lot of luck getting early users to just either create a new Amazon account and install everything there. Or we actually, we will create a whole bunch of, we pre-create a whole bunch of Amazon accounts, and just hand them out to people to let them start trying stuff. Anything we can do to reduce the amount of stuff that they have to do to get in and get experimenting, I think is really valuable.

    Steve: Yeah, that’s a really good point. Something we’re not doing yet at my current company but we’ve done in the past is create these real demo environments, where, you know, without creds even, people can try the product out online and get a sense for what it will be like without signing up, which has been a really useful tool for me in the past.

    David: Yeah, it can be pretty tough to do that with developer tools, just because, you know, you are talking about complex integrations in a lot of cases, but yeah, I think hugely valuable, when you get that right. If I’m a couple clicks away from actually playing around with the product, and maybe even a couple more clicks from you know, taking what I’ve been playing with and going live with it, any friction you can reduce in that path is going to help.

    Steve: Yeah, that actually raises an interesting point about the transition over the last few years from how enterprise software companies used to sell to how they seem to be selling now, which is the transparency, that now, things like pricing, and a real sense of what the product does. It all sounds pretty basic, but, these were things that you wouldn’t expect to see, five, 10 years ago. That selling a B-to-B product—you would have a button to contact the salesperson, and you might not even know what the product did on the homepage.

    David: Yeah, that’s exactly right, I mean, you still see a lot of that today, and it’s incredibly frustrating as a buyer of software to run into one of those. We try and keep in that in mind a lot when, from the other end of that it’s knowing how much it’s going to cost to knowing exactly the value that it’s going to provide for you, and how it’s going to make your life better, is really important.

    Steve: Yeah, it seems so obvious just to design your marketing at least so that people know what the product does when they come to your website. I can’t imagine a consumer company dealing with some of these issues, like the problem of multiple environments, and that we get people signing up with personal accounts, or with staging environments that are not the intended use of the product at all, but in order to win these customers over, we have to show value in them.

    David: Yeah, it’s tough, I mean, those environments can basically be completely different too, right? Like, my personal IDS account maybe has nothing in common with what my company’s looks like, you know, it’s like almost as if somebody wants to test your iPhone app by installing it on their Android phone at home first. It can be wildly different.

    Steve: Yeah, we were actually talking the other day about having kind of a ‘clean up’ button, where because we know so many people are onboarding this way, putting us in a staging environment or something first, that, they’ll have to kind of decommission some things and remove some things that they created in that first environment before moving to the other one. And so we’re trying to make that process easier for them too, as part of our onboarding. Which just seems ludicrous, but, it’s funny to talk about.

    David: Yeah, it’s almost worth trying to, is there some way that you can, through permission sets or something, like actually introduce them slowly into the production environment in a trusted manner, as opposed to here making them go through this experimentation phase first.

    Maybe if it was very guided, it might be possible to pull that off. So, you mentioned dealing with customers sort of on a one-on-one basis, in kind of a very high-touch manner, and that’s something that we’ve had a lot of success with, and we actually think is really important, you know. We have a public slack channel, we invite people to come in, we talk with people all the time, they ask questions about the product, that ask, you know, if they’re having problems, or if they, you know, even questions about Amazon, sort of things that are not even directly related to us, and kind of get a conversation going about that stuff.

    It’s been hugely valuable to have that kind of real-time, you know, I can just ping somebody and kind of get to know our customers individually, and know what they’re building, kind of the problems that they’re having, and that’s been really helpful.

    Steve: Yeah and, not only that we get to interact with them in real time, but we have a way of reaching out to them, and that, one of the issues we have, I think, as an early-stage company is that people are trying the product, they’re not necessarily engaged with the product, and they may not tell us about that.

    And so, having every possible way to reach out to them, but also then making part of our onboarding process actively reaching out to them during this process, and making sure they’re getting value, and seeing if they’ve found bugs, and just doing everything that we can on our side to make sure that they’re happy and engaged.

    David: Yeah definitely, I think, I mean reaching out, kind of keeping the engagement level high, and reaching out constantly, like, you almost always have to solicit feedback. I mean, you’ll get some really awesome customers that will come and tell you everything that’s wrong with your product, and those are great, but, for most people, you have to actually solicit that feedback. A lot of the best learning we’ve done in our onboarding process, and finding where the friction is, is just talking to somebody and seeing the questions they ask, you know, sometimes they’ll be like, completely off base, or weren’t even in the ballpark of things you were expecting them to ask, you know, you’re expecting them to ask, ‘How does something work,’ and they’re asking, ‘What does this thing even do?’

    Steve: Yeah, I think you raised two really interesting points there: one is like, when I was new to this, both new to startups and new to designing technology products, I used to take offense from that feedback. ‘How dare you criticize my work.’ But, as you were saying,

    The most vocal customers are the best ones. The ones who are going to tell you about every single bug, I cherish that now. That’s what we look for in our Beta customers.

    David: Two reasons: one, it exposes all of the things that you hadn’t seen, and two, those customers are actually your biggest opportunity to make them successful. If they’re engaging with you enough to tell you what’s wrong, they want it to work badly enough that you can just help them a little bit and they’re going to be great.

    Steve: Yeah, totally, if nothing else, if they’re complaining it means they care enough to complain, and like we were talking about earlier, partly because our onboarding processes tend to ask a lot of our customers, and because that can take significant time, it’s really on us to engage with our customers and figure out how we can help through that and how we can make it easier for them, and so, because of the burden on them, it’s a big thing for us to both learn how we can make that better, and also help them help customers through it as best we can.

    David: One of the interesting things that we’ve been seeing is that we get not only really technical people coming through our onboarding process. We get some very technical developers that kind of understand the basics of what’s going on, and they have one set of questions.

    We get other people that are maybe a development manager, or, in a lot of cases, I had one ops guy and he’s now AWOL and I can’t get in touch with him, and I just need help, and they have a completely different set of things that they’re looking for when they come to talk to us. It’s been really enlightening to be able to talk to all of those groups, and kind of see what it is that they’re looking for, because it’s very different.

    Steve:  Yeah, we, in speaking to the different kinds of people using the product, there seems to be a transition happening in that way dev teams are set up. And so, we’re dealing sometimes with developers, sometimes with operations people, sometimes people who identify as DevOps, and it’s almost like we have to learn something about the organization first, how their team is set up, and how they deploy infrastructure to even get a basis for the level of conversation that we’re having. And the level of knowledge—yeah, like you were saying, it could be anyone from a manager, I even had a couple of product people contact me. And so yeah, just establishing how the team is set up has been really important to figuring out how to talk with our customers.

    David: Yeah, understanding who makes decisions about that kind of stuff, understanding how new technology is deployed at their company, you know, it’s different for everybody. Like, some people are very gung ho, they just take new stuff and go crazy with it all the time, and some companies are very conservative, and it’s a lot different to get sort of the new shiny things rolled out for them.

    Steve: I think the contrast of, and we were talking about this a bit earlier, broad vs. deep, and open source vs. SaaS, so I think, Convox’s case is really interesting because you’ve got both an open source product and a SaaS product. Can you talk a little bit about the contrast and the priorities of designing those two products?

    David: Sure, yeah, I mean, so, it starts right at the beginning. Like you mentioned, we have the open source, we have SaaS, our SaaS product is not open source, so, there’s just fundamentally different ways that we work on those projects even, you know, with the open source we work in the open. We do a lot of discussion with the community before we make changes, you know, pull requests, and trying to get a lot of people involved in the changes and make sure we’re taking all kinds of viewpoints into account that is going to be useful for a broad range of people.

    And then, with the SaaS layer we’re basically saying, ‘Okay, we know have this opinionated, this is how you should be using this, and this is we’re going to codify the happy path, the way that you, the easy, couple-of-clicks way into the product that uses all of this crazy technology that we’ve built.’

    Steve: Yeah, and the contrast there is really interesting because open source tools almost by definition have to appeal to a wide audience, you want as many people as possible adopting them and contributing to them. That’s I think a big part of how they develop traction is you get an engaged community of developers who want to help, and SaaS almost seems the opposite, that, a really common startup mantra is this: ‘Make a few customers love you as opposed to a lot of people like you,’ and so, making a great, polished experience for a much smaller number of people seems really important to developing a SaaS business.

    At Opsee we’re dealing with this too, we’re only SaaS, we have no open source component, and so we really are trying to focus on a narrow set of use cases, and then make them as polished and perfect as possible, and we are competing with open source tools. So, sometimes we will see these responses like, ‘Oh, why would I pay for your tool when I can get the open source for free?’ But then there’s this back and forth about the development time required to customize it, and the different nature of those kinds of tools.

    David: And operating it, you know, it may be free, but somebody has to run it, somebody has to write a page up for it, and it’s easy to lose sight of that stuff.

    If you’re interested in being a guest on the show, or if you have a DX topic you’d like us to dive into you can reach us at dmmc@heavybit.com or @dontmakemecode.

  • To Be Continuous: Empathy in Software Development

    To Be Continuous: Empathy in Software Development

    Thanks for listening to To Be Continuous, a show about Continuous Delivery and software development hosted by Paul Biggar, Founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly. In this segment of To Be Continuous, Edith Harbaugh and Paul Biggar talk with Sam Stokes about empathy in software development, how mini-services are the new microservices, and constantly updating software in a constantly updating world. Sam is currently a freelance software consultant and previously was the co-founder of Rapportive.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/237727552?secret_token=s-k6OKe” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=flase” width=”100%” height=’166′ iframe=”true” /]

    Paul: Alright, Sam, so what’s your favorite thing about continuous delivery?

    Sam: I like to think about it terms of shortening feedback loops. A lot of things that startups do can basically be looked at as doing something and then waiting to get some feedback on it, and then deciding whether to do more of that thing or to do a different thing.

    And continuous delivery is, people talk about sort of reducing the batch size and also about shipping stuff faster and clearly having some kind of automation. And continuous delivery is going to help you with both of those things.

    Paul: So is this specifically on the, sort of on the journey of a small startup towards product market fit? Is that kind of the sense you’re thinking of it as?

    Sam: I see it as applying to teams of different sizes. So for sure in a small startup you’ve got you need to iterate fast, you’ve got all these product ideas. But I think even if you’re a small team in a big company as I was recently working on, and still have a lot of the same pressures you have, product managers who want to try new ideas, you have customers who are sending in feedback all the time—some of which you want to listen to, some of which you want to tune out.

    It’s sort of, in some ways, a lot like being in a startup. At least, ideally it would be. And a lot of the problems you can run into are basically about not being able to close those loops quickly enough.

    Edith: Sam you’re someone who knows a lot about loops, so now might be a good time to introduce yourself.

    Sam: Sure, my name is Sam Stokes. Until recently I was working as a staff software engineer at LinkedIn. And right now I am, I guess a freelance software consultant, thereabout.

    Paul: I feel there’s a little bit of history missing there.

    Sam: Alright. Going back in time a little bit. So I was a co-founder of a startup called Rapportive. That was a plugin for Gmail that when somebody emailed you, would show you a social profile of that person in the right-hand side next to their email.

    So that you could get some insight into who you were talking to and put some more humanity into your communications with people—that’s sort of the way we saw it.

    Paul: That’s still the only plugin to Gmail that I use.

    Edith: I use it, too, and it’s for exactly that reason, ’cause I do a lot of customer development, and it helps so much to do, to empathize. To see that this—

    Paul: Right, right, yeah is a real person.

    Edith: You know, to see their face and you feel a connection.

    Paul: It’s interesting just with kind of customer communication. One of the tools that we use is Intercom. And once I started using Intercom it was the same sort of feeling I got the first time I used Rapportive, that like I feel that there’s a human at the other end of this and I feel I know who that human is and it just changes how you communicate with the people.

    Sam: It’s really motivating to hear and to see other examples as well. We really felt like email and sort of a lot of business communication in general can be sort of cold and formulaic.

    Yeah, just bringing that human element, even just seeing a face. I haven’t used Intercom but I’m guessing they have some similar ideas.

    Paul: Similar, when you send out messages or reply to someone it does the person’s face there.

    Sam: Right, we had a sort of plugin API in the, it was a sort of private beta version of our product and one of the things people used it for, so this would let you plug into the sidebar, people would plug it into their customer database and so they could see something like, they’d get an email from a customer it shows them how long they’ve been a customer, how much they’ve spent in their store—

    Paul: Right, right.

    Sam: What version of the app they’re running, that sort of thing.

    Edith: Was your original idea to do that sort of empathy or was that something that just you iterated into?

    Sam: The empathy was where we started. There were lots of ideas about taking all the information from all these different sources, you know public sources like, truly public sources like Google, quasi public sources like a Facebook profile if you’re friends with them on Facebook, and then private sources like stuff in your company database.

    All stuff that you would be able to search for if you could be bothered to go and do the searching but doesn’t necessarily bring itself to you while you’re talking to that person. And yeah, it was very much, what should you know when you’re talking to this person in order to make them feel like they’re interacting with a real person and an empathetic one.

    Paul: So I remember when you launched Rapportive it was like, or it felt to me like it was, an instant hit and maybe that was just the overnight success that comes after years of trying. I had a doco and what was the kind of software delivery process of that?

    Sam: Hmm, that’s a great question. I guess there’s two parts to that really. So how did it get there and what was our process that allowed us to survive it? So I guess how did we get there, it was a certain amount of luck in that process as there probably always is. We built our prototype and it was a pretty minimal prototype.

    You know, it had the functionality that was like this awful demo website up. The only reason there was a website up was we were trying to raise a seed round at the time, we were applying to OIC. Y Combinator requires that you have a demo site that’s public. They don’t like it to be password-protected. And so we had this thing up where you could install it and we had like 20 users. One of our friends decided that he was going to email a friend of his at one of the blogs, I think it was ReadWriteWeb and say, you know, hey you should check this out.

    And his friend checked it out and it turned out that one of the demographics that really liked the product that we built was journalists because they get a lot of emails from people they don’t know and they want to sort of know an extra nugget. I guess that was one of our takeaways was like, if your startup is really useful for journalists, that’s a great way to get some early press.

    Edith: That’s what worked for TripIt because journalists travel a lot. So TripIt just got all this free press basically ’cause journalists used it, loved it, and blogged about it. Unfortunately, journalists do not do continuous delivery so much.

    Sam: So how do we survive that? ‘Cause what happened in that 24-hour segment was that we went from 20 users up to 20,000.

    Paul: Wow.

    Sam: So I guess one part of it was our CEO had made the original platform choice. His name’s Rahul Vohra, he has a computer science degree, he’s an awesome technologist, but his focus is not generally on writing the software. He’d been writing the prototype, and he was like, ‘I need the quickest thing that I can get to get this market, so I’ll put it on Heroku.’

    Which turned out to be a life-saving decision because when the 1,000 X traffic spike arrived we just added some more dynos. So that was how we didn’t burn down. What did we do after that? I guess in terms of software process we were pretty young as a company, so it was pretty much hack away, read all the tweets. But there was a lot of, what you might call customer development more than software development at the time. So we pretty quickly decided that we were going to try and respond to every single tweet and every single email and so on to like try and live this idea of a good customer experience.

    And I think that helped to sort of amplify the viral effect of that press spike because people were sort of retweeting the things we were saying and getting a generally good feeling about us.

    And so a lot of those tweets were like, ‘Oh I wish I did this,’ or ‘I wish I did that,’ or ‘I wish you could see Twitter profiles in there.’ So it was a little bit of sort of customer support-driven development. Which obviously doesn’t scale but it can be a pretty good way to build some goodwill early on.

    And I think a lot of our users were sort of quite passionate about using us, ’cause they felt like they got that personalized attention.

    Paul: So did the, when you scaled the dynos did it just work?

    Sam: It worked perfectly until we hit the rate limit for the API that we were getting all our data from.

    Paul: The LinkedIn API?

    Sam: At the time we were using a service called RapLeaf.

    Paul: Oh yeah, yeah, I remember them.

    Sam: It wasn’t their main product, but they provided an API which … So basically the thing that Rapportive does, which is take an email address and produce social profiles about that email address. At the time that was entirely just UI wrapped around RapLeaf. We ended up building sort of our own version of that.

    And so we’d been using their API on a sort of demo basis. Because again, 20 users. Yeah, we immediately had to learn about things like request queues, so that our app wasn’t just falling over waiting for their API, and then frantically Biz Dev-ing to try and increase our rate limit, while at the same time figuring out the best ways to get around the rate limit without upsetting the Biz Dev deal. Yeah, we didn’t really have much of a sort of continuous delivery process at the time.

    But I guess not as many people were talking about it—this was 2010. I think the first blog post had come out from Iron View and so on, but I think it wasn’t as, you know, there weren’t full startups supporting it. What we did have was the Heroku deployment model, which was basically like within five seconds of writing the code you can deploy it to production.

    Which if you squint at it, kind of is continuous delivery because you’re saying, all of the bits of your deployment that you have are automated. We didn’t really have many tests at the time, so the tests we had were automated ’cause there weren’t any. Our deployment was absolutely, you do it get push, you don’t have to like move any servers around or anything like that.

    Paul: Seems like the testing model around, or the continuous delivery model around a Gmail plugin is probably going to be a fairly difficult process anyway.

    Sam: We never really had a good answer to, you know, what happens when Gmail changes their UI. The surprising part was it didn’t happen that often. We thought it would be breaking every week and we’d need all kinds of canary accounts and end-to-end testing to monitor that kind of thing. In the end, it happened rarely enough and we noticed quickly enough that we could usually just fix it on the spot. So even when we got better at testing and that sort of cycle of things.

    Paul: We had a problem or I guess solution with GitHub. So GitHub used to be super flaky around two, two and a half years ago, when they were still on Rackspace. And whenever something would go wrong with GitHub we would find out immediately. All of our, all the developments would start failing and so before they knew that there was a problem, we knew there was a problem.

    And we would often like, declare on Twitter, oh we think GitHub’s having a bit of an issue and two minutes later their status would tweet us and then we would retweet their tweet.

    Edith: So they were using you for their free testing.

    Paul: Well, our customers at least.

    Edith: No I mean you were acting as their tester and telling them that—

    Paul: Well, I mean it was very, you know, automated on our but we didn’t have necessarily automated fixes at the start. It kind of happened every, you know, two or three months and they would swear this is the last time and—

    Edith: It’s always the last time.

    Paul: And in the end it happened like six or eight times and by that time we had built a thing that allowed, you know, certain fixes, but it wouldn’t be quite, you know, fully automated process that you would expect if it was happening all the time ’cause it always seemed like it was gonna be the last time.

    Sam: And it’s probably always happening for a slightly different reason or in a slightly different way. It’s actually, it’s an interesting question to me in the subject of continuous delivery in general. People always talk about every time you commit you run your tests, every time you commit, you deploy.

    But that’s actually only one of the kinds of events that you’re dealing with in a software life cycle, right, when something’s actually running. I mean, sure you’re changing the code but also the world’s changing around you. And I feel like you always end up needing a little bit of both—you need something that’s gonna trigger when you change it, but you also need sort of an eye on everything you depend on. And, of course, even figuring out what all those things are can be interesting.

    Paul:

    So I wrote a blog post about this on the Heavybit Blog, I think a while back, and it was about third-party APIs you know, how do you test third-party APIs. And the conclusion that I came to was that, so if you run the tests as part of your test suite, then if something breaks, your test suite will be broken, but also some things will just like randomly break in production.

    And then of course you can’t deploy because your test suite is broken. So you’re in kind of the worst of both worlds. And so what I considered is, is that you need something which, you know, is just permanently monitoring. Like whatever API things you do constantly hits your personal accounts or your test accounts for those things, and then stub it out in your test suite.

    And that way you kind of get that best of both worlds, your test suite doesn’t fall over and you get an actual monitoring event when the third-party service goes down in production.

    Sam: I can tie this to an experience from LinkedIn, actually. So LinkedIn has the model where there’s a staging environment and a production environment. And the staging environment is—I don’t know if it’s technically called a staging environment because it’s not exactly production-like, but what they actually call it is early integration. Because it’s the environment in which teams integrate with other teams.

    And so the idea is you deploy your stuff into EI, early integration, as soon as you can so that if any other team depends on you or vice versa, you can find out there before the thing hits prod. But what you’ve effectively got in EI is this constantly changing environment full of dependencies and you have exactly this problem and different teams which using different solutions to, well, let’s write some integration tests which actually hit the dependencies and then we’ll run them in our test suite when we deploy to EI or when in the build step which—

    Paul: I can’t tell as you’re describing this whether this is a good thing or bad thing.

    Edith: Yeah.

    Sam: I think there wasn’t a clear conclusion, but my conclusion is that it doesn’t work for the same reason that you’re saying.

    You need to know that if your test suite fails, it fails because of something you did. And then you need something else that can fail because of something someone else did.

    But if you’re ever unsure which of things it is, then the signal is lost for both systems.

    Be sure to listen to the full episode. While you’re there check out Heavybit’s library, home to great educational talks from other developer company founders and industry leaders.

  • DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    tyler jewellI had a chance to sit down with Tyler Jewell, CEO of Codenvy.  Tyler is an experienced tech exec and VC participant.  I met Tyler recently at the CloudBees CD Summit and Jenkins User Conference in Santa Clara. Tyler’s present company is Codenvy.  I spoke to Tyler about why and how leadership should engage DevOps.  Tyler says leaders need DevOps. You can listen below or read along. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505270?secret_token=s-gFEIj” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Alan Shimel:                Hi, Alan Shimel, devopsy.kinsta.cloud here for another Devops web chat on the Leadership Suite. Our guest today is Tyler Jewell who’s CEO of Codenvy. Tyler, welcome to Devops chat.

    Tyler Jewell:                Thanks for having me.

    Alan Shimel:                Tyler, I guess we should start off with those of our listeners who may not be familiar with yourself or Codenvy, why don’t you give us a quick background?

    Tyler Jewell:                I have been working at Enterprise Software for 25 years. I started off as a software engineer and then held a number of positions in product management at companies like BEA and Quest Software. The past six years I have been a venture capitalist, a partner at Toba Capital, investing in midware, Devops, and developer related technologies and while there at Toba Capital I founded and run Codenvy, which is now three years old.

    Alan Shimel:                Great. So another overnight success, huh?

    Tyler Jewell:                Business is good and there’s a lot more to be had.

    Alan Shimel:                So Tyler, for those of our listeners who may not be familiar with Codenvy, what are you guys doing over there?

    Tyler Jewell:                We are in the business of providing continuous development solutions, which is a part of Devops and continuous delivery. We do that by delivering on demand develop or work spaces that are easy to replicate, are constraint free, and collaborative.

    Alan Shimel:                Great. So Tyler, our audience for these chats are really managers, executors who are managing software – well, every companies a software company today, right? But these are people who are managing software departments and managing software delivery. Why should they care about what problems Codenvy is solving?

    Tyler Jewell:                Well, I think that there’s an interesting statistic that says 88 percent of organizations are now pursuing a Devops strategy and that’s just a phenomenal statistic in my mind considering that the term Devops did not appear before 2010. So in five years we have had essentially market saturation, and so why is that? And that’s the case because ultimately organizations that can release more frequently are able to drive customer happiness and this ceiling, this philosophy, has so many truths to it that software organizations are assessing their ability to deliver continuously at all stages of the pipeline.

    Where Codenvy fits into this is that we are providing continuous concepts to the pre-commit or the pre-merge phase of the pipeline, which is where the developers spends his time, and frankly where the developer spends a lot of their time configuring it and not coding.

    Alan Shimel:                Tyler, what about sort of system architects, system planners? Are they part of the Codenvy value chain as well, sort of even before the code, the proverbial papers taken into pen to paper, when we’re planning new apps and new software?

    Tyler Jewell:                Well, I think that historically the code has been the domain exclusively of the developer and there’s really no reason for that and that the code can become the domain of all audiences that are part of the software team, including the architect, but also the QA engineer, the product manager, the project manager as well. And essentially if you’ve been someone who has wanted to bill code or to run or debunk the code you needed to be a developer and set up a developer work space.

    That was a very technical skill set that you needed to have. In this day and age with the advent of containers and a lot of the automation that has been built into our technologies there is no reason that you need to be technical to recreate a developer environment. You can do that with URLs. You can do it online without installing software. And when you do you can allow users, your QA engineers, and product managers to get a feedback on to the code along with the engineers having these environments without overhead.

    Alan Shimel:                Got it. And Tyler, so we have this – to many people and especially to a lot of managers, execs, Devops is sort of developer led, but we’re also seeing this movement of IT ops, right? And as IT ops folks between to code more and infrastructure code starts happening more do you think we’ll see a migration from sort of Devops to IT ops being dominate here with this?

    Tyler Jewell:                Well, I think what we’re looking at is it’s a feedback driven initiative here. So whether it’s a developer or a development organization or an operations organization that is the driving initiative, the common goal here is to find ways to get feedback earlier into the life cycle. So whether that is an operation’s engineer or a developer it’s really about the people who value that feedback the most and can benefit from it.

    And feedback exists at every stage of the pipeline among all the different departments that are there and they all benefit from having that feedback as well. So I think they’re all gonna become drivers in their own way and they’re – any barriers that exist between them are gonna increasingly come down including perhaps their titles and job responsibilities as well.

    Alan Shimel:                Sure. Tyler, one of the functions of executives, especially IT executives, is we service somewhat of a translator between our very technical teams that we work with such as developers, such as IT ops or QA and even security. Between that group and then translate that into business speak for our peers who are perhaps CFOs or CEOs or nontechnical executives in the team. When we talk about the kinds of problems that Codenvy tackles, how can executives translate that into business speak that they’re CFO and CEO understands?

    Tyler Jewell:                Well, I think that if you are an organization that depends upon software either to be differentiated with your products out in the market place or to just be more efficient, the leap that CIOs need to make with their peers is that software teams that are high functioning are those that are able to release the most frequently here.

    So having a benchmark of release frequency, comparing that to your own ability, and then assessing your technological people in cultural capabilities along those lines is a simple way that you can start to communicate the benefit of having a very efficient software development organization that is embracing these technologies and philosophies. If that kind of assessment and narrative does not work then I think you have to take it back to perhaps manufacturing fundamentals, the theory of constraints here, which goes that if you want to produce a high volume, high quality parts, physical parts, you have to focus in on the portion of the work flow that is the slowest and most _____. And by resolving that and making that the most efficient then the entire manufacturing process becomes more efficient and software is the same philosophy. It’s just done with bits as opposed to screws and bolts.

    Alan Shimel:                Got it. Tyler, let me ask you to step back from your role as CEO of Codenvy for a second and put on your hat as someone as you said has 25 years’ experience in IT who’s served on the venture side of the house. What do you see as the biggest innovations or trends that executives should be watching around this whole new way of doing software and apps?

    Tyler Jewell:                Well, I think that they’re – as an investor at the very basic investment thesis in that the demand for software is increasing at a faster pace than the supply of engineers exist to produce it here. And so the only way to revolve this demand supply curve or this inequality that exists is that there’s gonna have to be tremendous innovations that show up that allow us to create software 10 or potentially even 100 times faster than we have in the past. And businesses and technologies that play to those trends are going to have outsized returns versus vendors who are not playing to those trends.

    So I think that’s the way I think about it and that’s abstract level. At a very concrete level the things that are playing to that, containers are absolutely fantastic. They provide low overhead. They also provide the programmatic definition of infrastructure which is something that we’ve never had before. So their rising adoption and popularity are a reflection of that. At the same time we’ve started to see new evolution of programming languages.

    Programming languages that are special purpose or domain specific are particularly geared towards Cloud development and those are making developers a ton more productive. And at the same time I also think that we’re continuing to see the rapid mobilization of knowledge workers around the world. We still have not seen a high penetration of that and there’s a lot more penetration to come. So those trends are inevitable trends that are playing into this Devops’ philosophy.

    Alan Shimel:                Got it. Last question, Tyler, and it’s the same one we ask everyone who appears on our show. For your executors out there, if they should read one book that will really help them with trampling with all of these kinds of issues and further their careers, what would you recommend?

    Tyler Jewell:                I’m a huge fan of Stephen O’Grady’s book that he wrote. It’s a two hour read. The title of that book – and this is my older age slipping my mind here – it is Developers are the New Kingmakers.

    Alan Shimel:                I know the book.

    Tyler Jewell:                It’s a fantastic read and I think that the book provides a very non-emotional explanation for why developers and development teams behave the way they do.

    Alan Shimel:                Yep. Excellent. Hey, Tyler, Tyler Jewell, CEO of Codenvy, thanks for being this week’s guest on Devops chats and much continued success with Codenvy and we hope to have you on again soon.

    Tyler Jewell:                I look forward to coming back. Thank you so much for having me today.

  • Jeff Knupp of “DevOps Killing the Developer” on Linuxinstall Podcast Tuesday

    Brian Wagner and Linux Install Podcast team will feature Jeff Knupp on tomorrow nights show.  Of course Knupp wrote the controversial “How DevOps is killing the developer” blog article last week which touched off a firestorm. This week Knupp will respond to some of the criticism and and further discuss his views.

    In last weeks episode of the linuxinstall.net the team took author Jeff Knupp to task for his article “How ‘DevOps’ is Killing the Developer”.

    Linuxinstall.net will be recording live on Tuesday April 22, 2014 @8PM with Mr. Knupp.  He will be on to discuss the article and the significant response to it.  If you have any questions for him please let the linuxinstall.net team know via Tweet(@linuxinstall), Google+(https://plus.google.com/+LinuxinstallNet), or via E-Mail podcast@linuxinstall.net.

    Should be a good listen!

  • Episode 2 of devopsy.kinsta.cloud Podcast

    Episode 2 of devopsy.kinsta.cloud Podcast

    Mitchell Ashley and I are joined this week by Stephen Wilson of Compuware. Stephen is a regular blogger here on devopsy.kinsta.cloud, but is also the technical evangelist at Compuware.  Steve gives us his background and a brief description of what Compuware does.  Then we all talk a bit about Steve’s last article here on devopsy.kinsta.cloud,  Don’t worry testing team, DevOps is here!. While some say that testing is a big loser in DevOps and many testing/QA teams feel a threat to their job security, Stephen says not true.  In fact DevOps makes the testing team superstars. Tes.com ting teams should embrace DevOps as it will make their job easier and more powerful, but not less important.  Steve talks about the concept of “continuous testing”.  All of this in just about 13 minutes.

    Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/142563047″ params=”color=ff5500&auto_play=false&hide_related=false&show_artwork=true” width=”100%” height=”166″ iframe=”true” /]

    Also if you would like to be a guest on a future devopsy.kinsta.cloud podcast write us at podcast@devops.com