YouSaid · the spoken record
Gene Kim
- lines on the record
- 72
- first
- 2020-03-06
- most recent
- 2020-03-06
- sittings or episodes
- 1
- sources
- podcast
Every line below is reproduced as it was said and linked to the record it came from. Nothing here is summarised or generated. Directory · Search · Corrections
“High performers get it all. Performers kind of suck at all of it. Medium performers hang out in the middle. I'm not seeing trade-offs. Four years in a row, so anyone who's thinking, oh, I can be more stable if I slow down. I don't see it.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“So, in the lean kind of discipline, this is called percent complete and accurate. And it's a measure of the quality of your process. So, in a high quality process, when I do something for Nicole, Nicole can use it rather than sending it back to me and say, hey, there's a problem with this. And in this particular case, what percentage of the time when I deploy something to production, is there a problem? Because I didn't test it adequately. My testing environment wasn't production-like enough.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“MTBF, right? Mean time between failures. If you only go down once a year, but you're down for three days and it's on Black Friday, but if you're down very small, very, very small blast radius and you can come back almost immediately and your customers almost don't notice, that's fine.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“The other one is release frequency. So, how often do you do it? And then we've got two stability metrics. And one of them is time to restore. So in the event that you have some kind of outage or some degradation in performance in production, how long does it take you to restore service? For a long time, we focused on not letting things break. And I think one of the changes, paradigm shifts we've seen in the industry, particularly in DevOps, is moving away from that. We accept that failure is inevitable because we're building complex systems. So not how do we prevent failure, but when failure inevitably occurs, how quickly can we detect and fix it?”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“A lot of it comes from lean. So lead time, obviously one of the classic lean manufacturing measures we use. How long does it take? You look at the lead time from checking into version control to release into production. So that part of the value stream, because that's more focused on the DevOps end of things.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, and it's interesting because Jez talked about in his overview of Agile and how it changes so quickly and we don't have a really good definition. What that does is it makes it difficult to measure, right? And so what we do is we've defined core constructs, core capabilities, so that we can then measure them. We go back to core ideas around things like automation, process, measurement, lean principles. And then I'll get that pilot set of data and I'll run preliminary statistics to test for discriminant validity, convergent validity, composite reliability. Make sure that it's not testing what it's not supposed to test. It is testing what it is supposed to test. Everyone is reading it consistently the same way that I think it's testing. I even run checks to make sure that I'm not inadvertently inserting bias or collecting bias just because I'm getting all of my data from surveys.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Right, just to quickly break down the survey methodology questions that people have in the ethnographic world the way we would approach it is that you can never trust what people say they do. You actually have to watch what they do. However, it is absolutely true, and especially in a more scalable sense, that there are really smart surveys that give you a shit ton of useful data.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“I think that the problem that a lot of people have is that we're so used to couching these things as trade-offs and as dichotomies. The idea that if you're going to move fast, you're going to break things. The one thing which I always say is if you take one thing away from DevOps, it's this. High performing companies don't make those trade-offs. They're not going fast and breaking things. They're going fast and making more stable, more high quality systems. And this is one of the key results in the book, in our research, is this fact that high performers do better at everything because the capabilities that enable high performance in one field, if done right, enable it in other fields. So if you're using version control for software, you should also be using version control for your production infrastructure. If there's a problem in production, we can reproduce the state of the production environment in a disaster recovery scenario, again, in a predictable way that's repeatable. I think it's important to point out that this is something that's happened in manufacturing as well.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Right, so Because that's how I'm kind of hearing it. No, absolutely. So you still need development, you still need test, you still need QA, you still need operations, you still need to deal with technical debt, you still need to deal with re-architecting really difficult large monolithic code bases. What this enables you to do is to find the problems, address them quickly, move forward.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“That's actually really important, the mere question of does this work is something that people really clearly don't pause to ask. But I do have a question for you guys to push back, which is, is this a little bit of the cult? Oh my God, it's like so developer-centric. Let's be agile. Let's do it fast our way, you know, two pizzas. That's the ideal size of a software team. And, you know, I'm not trying to mock it. I'm just saying that isn't there an element of actual practical realities, like technical debt and accruing a mess underneath all your code and a system that you may be there for two or three years and you can go after the next startup, but okay, someone else has to clean up your mess. Tell me about how this fits into that big picture.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Absolutely. So in the situation where the thing you're building has no characteristics and it's been done before, yeah, sure, we can take a very phased approach to it. And, you know, for designing these kind of protocols that have to work in a distributed context and you can actually do formal proofs of them, again, that makes sense. But when we're building products and services where particularly we don't know what customers actually want and what users actually want, it doesn't make sense to do that because you'll build something that no one wants. You can't predict.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Okay, so if you go into the crypt of the Sagrada familiar, you'll see his workshop, and there's a picture, in fact, a model that he built of the Cigrado familiar, but upside down with the weight simulating the stresses. And so he would build all these prototypes and small prototypes because he was fundamentally designing a new way of building all Gaudi's designs were hyperbolic curves and parabolic curves, and no one had used that before.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“If the thing you're building has well understood characteristics, it makes sense. You plug the parameters into the model and then you get a trust bridge and it stays up. Have you been to Sagrada Familia in Barcelona?”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“The way I think about this is I remember the stories of Microsoft in the early days and the waterfall cascading model of development, Leslie Lamport once. Wrote a piece for me about why software should be developed like houses because you need a blueprint. And I'm not a software developer, but it felt like a very kind of old way of looking at the world of code.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“We hope that day two is really, really long. And we're fond of saying Agile doesn't scale. Sometimes I'll say this and people shoot laser beams out of their eyes. But when we think about it, Agile was meant for development, just like Jez said. It speeds up development. But then you have to hand it over, and especially infrastructure and IT operations. What happens when we get there? So DevOps was sort of born out of this movement, and it was originally called”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Getting there on and on. And that really is where DevOps comes in. It's like, well, agile, we've got a way to build nivil products, but how do we keep deploying to production and running the systems in production in a stable, reliable way, particularly in a distributed context?”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, I can give you a very personal story, which was my first job after college was in 2000 in London working at a startup where I was one of two technical people in the startup. And I would deploy to production by FTP encode from my laptop directly into production. And if I wanted to roll back, I'd say, hey, Johnny, can you FTP your copy of this file to production? And that was our rollback process. And then I went to work in consultancy where we were on these huge teams and deploying to production, there was a whole team with a Gantt chart which puts together the plan to deploy to production. And I'm like, this is crazy. Unfortunately, I was working with a bunch of other people who also thought it was crazy. And we came up with these ideas around deployment automation and scripting and stuff like that. And suddenly we saw the same ideas that popped up everywhere, basically. I mean, it's realizing that if you're working in a large complex organization, Agile is going to hit a brick wall because unlike the things we were building in the 60s, product development means that things are changing and evolving and evolving all the time. So it's not good enough to get to production the first time. You've got to be able to keep.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“We didn't call it DevOps back then, but it's also more agile. Can you guys break down the taxonomy for a moment? Because when I think of DevOps, I think of it in the context of the containerization of code and virtualization. I think of it in the context of microservices and being able to do modular teams around different things. There's an organizational element. There's a software element. There's an infrastructure component, like paint the big picture for me of those building blocks and how they all kind of fit together.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“And you can make an analogy to what Agile was about since the kind of software crisis of the 1960s and people trying to build these defense systems at large, the invention of software engineering as a field. Margaret Hamilton, her work, MIT on the Apollo program, what happened in the decades after that was everything became kind of encased in concrete in these very complex processes this is how you develop software and agile was kind of a reaction to that saying we can develop software much more quickly with much smaller teams in a much more lightweight way”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“And I think from a historical point of view, the best way to think about DevOps is a bunch of people who had to solve this problem of how do we build large distributed systems that were secure and scalable and be able to change them really rapidly and evolve them. And no one had had that problem before, certainly at the scale of companies like Amazon and Google. And that really is where the DevOps movement came from, trying to solve that problem.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“So I started as a software engineer at IBM. I did hardware and software performance. And then I took a bit of a detour into academia because I wanted to understand how to really measure and look at performance that would be generalizable to several teams in predictable ways and in predictive ways. And so I was looking at and investigating how to develop and deliver software in ways that were impactful to individuals, teams, and organizations. And then I pivoted back into industry because I realized this movement had gained so much momentum and so much traction and industry was just desperate to really understand what types of things are really driving performance outcomes. Excellence by this”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source
“Hi, everyone. Welcome to the A6 and Z podcast. I'm Sonal. So one of the recurring themes we talk a lot about on this podcast is how software changes organizations and vice versa. More broadly, it's really about how companies of all kinds innovate with the org structures and tools that they have. And today's episode, a rerun of a very popular episode from a couple years ago, draws on actual research and data from one of the largest large-scale studies of software and organizational performance out there. Joining me in this conversation are two of the authors of the book Accelerate, the Science of Lean Software and DevOps by Nicole Forsgren, Jez Humble, and Gene Kim. We have the first two authors, so Nicole, who did her PhD research trying to answer the lusive eternal questions around how to measure software performance in orgs, especially given past debates around does IT matter. She was a co-founder and CEO of Dora, which put out the annual statement.”
2020-03-06 · a16z Podcast · Innovation Through Software Development and IT · IDENTIFIED FROM THE TRANSCRIPT · source