[Best of 2022] #100 - Modern Software Engineering - Dave Farley

Hey, a quick message, for those of you who are listening to this episode on Spotify, I have a small favor to ask Spotify. Now allows mobile users to rate podcasts, I would really appreciate it. If you can take a quick pass to go to the technique Journal podcast page, and leave your favorite show, your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot.

Today's clip is from package, you know, episode 100, With day Farley the one who runs the popular continuous delivery, YouTube channel, and also the author of continuous delivery and the latest book, modern software engineering in this clip. They've explained his view on Modern software engineering and why it emphasizes on the practices for building better software faster. They've described the foundations of the software engineering discipline, and explain the core competencies.

We need to succeed by becoming experts at Learning. For today, we will discuss mainly from your latest book, which is titled modern software engineering. The first thing that comes to mind for me, when I look at the title, why do you call it modern software engineering? Is there the old ways of software engineering? And there's a new modern way of software engineering? We are able to talk with stuck in my mind for a long time.

While I was writing the book and to be honest I was somewhat nervous like the reason why I call it modern Subterranean rather than just software engineering and I was nervous, oblique white least kind of the same. I think. Now industry, we kind of weirdly devalued, what we think of as engineering.

I think it's very common to think for people to say, software development isn't engineering and a lot of it isn't that think that's fair and not get, isn't engineering, but in other disciplines engineering doesn't mean heavyweight bureaucracy, which I think is what it tends to mean to us. What engineering means in other disciplines is the most effective efficient by you're doing work of high quality.

And so if software engineering doesn't allow us to build better software faster, it isn't software engineering. So modern software engineering, I think he's different to what we're before we tried to implement engineering approaches before and they were nearly all one is narrowly focused on some particular set of tools or diagramming techniques or something like that and bureaucratic and heavyweight. And that's not what I mean at all. So, I mean almost entirely the opposite of that.

So what are you? Interested in politics by background and interests. My hobbies is that I'm very interesting science. I think that a reasonable definition of engineering is as a practical implementation of science. You apply scientific style reasoning, which is Humanity's best approach to learning to solving practical problems. And I think that's a reasonable kind of colloquial. Definition of engineering. I was always interested in those kinds of ideas.

What are the ID that we could point? Point two and whatever your technology, whatever, the problem you're solving, I don't organization that your work. If you applied these principles, you have a better chance of success. And I thought I'd spotted some of those things over time and they related to continuous delivery which was my previous book that I worked on with Jay. So humble and so on. But also somewhat separately.

The slightly different angle. It's kind of all cargo they intersect and they're very reinforcing at one another but they're not the same idea. So what would the principles that would allow us? To do a better job. And I thought that was what I was trying to explore, and that's what the title is meant to try. And convey the subtitle of the book itself is doing what works to build that the software faster. And in your book I also find it quite insightful.

Is that you mentioned that if our software development practices do not allow us to build better software faster, we should really change them because they are not engaged during. So please tell us more about this concept. Why do you think so? Why we should focus on building better software faster? The simple answer is, why would anybody want to build were software slower? I think it's the combination in car. This is my corner.

Again, colloquial take on the Dora metrics, the metrics that come out of the state of debauchery court. That give us a predictive model, if you work in these kinds of ways and do these kinds of things, you increase your chances of success and they are based on the stability met X. What's the quality of our software? When we introduced our current production, how often does he break? And when it breaks, how long does it take us to recover from the breakage and throughput?

What's the efficiency with which we can deliver software of that quality? So that's the faster part. So working quickly, one of the findings from the door and metrics which is important, I think is that there is no trade-off between speed and quality. One of the traditional assumptions is that if you want to build high-quality, Things, you need to go slowly what Medora report says is know, if you'd go slowly, you build lower-quality things and that's what the statistics say.

That's what a sociological approach to measuring the performance of subdued. Lot of teams finds the more barriers you put into being able to release change quickly, the

worse the output. So we want to be able to move quickly, we want to be able to go faster, and we want to be able to build better software, and that means that we need to be able to focusing on be able to learn, find out where mistakes are To in really quickly and efficient and that kind of these, one of the ways we displayed in with continuous delivery, can you still use a fantastic way of being able to build better software fast from my career itself?

I can tell that there's so many experience from my view, is that we build software faster in the beginning, but since that, after a long period of time, or maybe few months, it starts to get slower and slower. And maybe many people have left. They don't know about the context that domain problems. So, I think maybe some of the tools that we will discuss today can help people to really build better software faster like continuously. So, you have a definition about

software engineering, right? If I can read here, is that the application of empirical scientific approach, which you mentioned in the beginning, just now to finding efficient economic Solutions. So, the economic Solutions here is also quite interesting to practical problems in software. I know that you'll cover in the book that some of these keywords

are really important. Maybe if you can discuss slightly some of these terms, why do you think it's important to Define software engineering using Sweet. So, I was trying to get the simplest minimal description of what I was thinking. In terms of engineering. I was quite pleased with that description that you just read out because it's fairly lean. It's fairly concise, but I think he doesn't miss anything important.

So applying the reasoning, the rational approach of science, I think that one of the fundamental nature of science is that the difference is between science and almost. Everything else is that we start out assuming that we're probably wrong and that's a very Healthy thing to do in engineering, and in such a development at all. So we're going to apply scientific style thing in a lightweight, not overburdening, not bureaucratic way. But we're going to be informed

by that kind of thing. We're applying at solving practical problems. We're not doing theoretical researcher. Proving the quarks are the basics of particles or anything. We're building things. And so we've got to be practical and pragmatic. So the empiricism of engineering just trying stuff out, ultimately, it is a big part. Well, the economic part is

Again, part of engineering. If we are physicists, we can imagine building machines at a black hole, thinking about that practically economically in energy terms. We're not ready to do that kind of for us Engineers. We are building things and so there are always economic Straits at some level. That's about the amount of time and effort and money that they spent, but also economic constraints in the sense of the performance of our delivery.

Assistant and the performance of our software, the carbon footprint of the software that we create, that kind of thing. He's an interesting question for you need sewn, right? So I wanted to get that in there as well. So I think all of these different parts of the definition, kind of leaders in this direction of trying to organize our thinking in a more rational way and apply it to solving problems, and are of value to people in some way.

That's what I was trying to reach full with the definition. Thanks for that explanation about the software engineering. So, I think for us, we need to probably redefine some of our understandings of engineering is not just writing code that works and deploy it. I think that's a really good

point. One of the things that are obsessed with at the moment, he's watching SpaceX build their space Rockets to go to Mars. That's engineering Live on YouTube, you can kind of watch it happening in the real world, that's not theoretical. They're evaluating their ideas, their blowing spaceships off are learning from that.

They're making progress. My step and I think all of these things kind of coming to an engineering approach to solving problems and thinking about the ways in which stuff can go wrong and all of the time looking at out of he proved and refine our designs and a solution so that they'll better fit. The problem that we're trying to try to solve. For us to follow this definition of stuff, engineering you mentioned there are two things that we have to be expert at.

So one is actually to become expert at learning. This comes back. Probably to the scientific approach that you mentioned. If s is experts at managing complexity, maybe we can cover one by one. Let's start with experts at learning. So you mentioned there are a few key things like five things that we need to be able to practice in our software engineering or software development day to day. So what are those five things?

Yes, so experts learning, let's just like War I that support, first of all it's to do with this kind of scientific engineering philosophy of assuming that we probably wrong, we not going to start out with perfect vision. We're not going to be able to predict the business context, the technical context, the socio-technical context of how we organize ourselves to what, we don't know the results, and you both think at some level, we're going to get all of those

things wrong. And so we want the ability to make progress while we Open the at the start of the project where we don't have all of the answers yet. Therefore we want to optimize to be able to learn Microsoft, did some research into their own ideas and found that two-thirds of their ideas produces zero or negative value for the company. Single black female to learn which with a bad idea. So early on, if you wanted to be efficient.

So we want to optimize for Gail to learn all sorts of things. What the problem is that we're really trying to solve what our users really need to have to solve that problem. Why technical In fits. Does it really work? Is it releasable? Is it comply? All those things? You'll learn ways of doing that. Are we going to work in order to be able to do that? As you said, there are five principles that underpin, our ability to do that. So, we need to work iteratively.

We need to working many small steps so that we have many opportunities to connect. Look at what it is, the v2e and refine it. Oh that didn't work. Let's not do that anymore. That kind of thing. We need to take feedback seriously. We need to understand what information. Should we need to gather in order to help determine whether our ideas or our Solutions are useful for help?

Whether our products are landing with our customers, where there are tests are passing or failing, we want to optimize great feedback to do that. We want to also be able to work incrementally, want to be able to build systems or almost evolutionarily. So, it's a bit by bit knots. All in one, great, big chunk. So we want to be able to deal with these things more independently so that we can kind of car be as in certain if we working on big.

Scale divide up the work so that different parts of the organization can work on different parts of the problem. So working incrementally is part of all of that we want to work experimental e. If you want to start being more scientific, be more like engineers in our approach. Then we should apply a little bit of discipline around the way in which we think about making changes. And the key to that for me is to think experimental e. We want to make little predictions.

You want to say? Well this is the problem that we are. Looking at the moment we think if we did this thing this would improve that position on this problem. How would we tell? Whether that thing was and wasn't working, that's the difference between an experiment into that step of predicting, what the outcome is. And then carrying out the tests. So you could think of this as a etched with the product.

We think that if we do this thing, it's going to improve the sales or this region and will put it into production. See what happens or you can. Give it as a test. I think that the coach should do this thing. If it were to do this thing, this is the assertion that I would be able to make. Then I write some code to fulfill that assertion, these are ways of it working experimental e and that can. And for me has become pervasive. That's the way that I now think about and practice nearly all

change where I can. So what is it that I'm trying to do? How would I understand the results of this thing? And I'm just thinking in that way, doesn't need to be heavy weight, can be really Really short really efficient but it's just a slightly more disciplined organized. Way of structuring, I think that gives us better results and the last one is the empirical we already talked about your cases and Engineering is about real-world things. It's not about some Ivory Tower

imagination of a system. It's about the reality of it. So we need to gather feedback from production. We need to go to understand what's really going on. We need to be able to make practical decisions based on what it is that we find Elon Musk is building space. Setting check this. I'm sure that they're doing very sophisticated computer simulation, but at some point it builds the beds of metal and that they blow it up on a test and see how it works. That's how Engineers speak and

that's how they operate. If you look at the developments on any sophisticated end in think about an aeroplane aeroplanes used to be incredibly dangerous things in 2017. The equivalent of two, thirds of the population of the planet flew in commercial airliners and One person died that wasn't possible in the early versions of ever played. We have to go through that pain of things breaking and killing people. And so, when we won't do that

anymore, will relearn. So 8 is about what incrementally and growing, and learning based on mistakes that we make fundamentally. And we've got to give ourselves that freedom to be able to operate that way and to make those kinds of mistakes books when they occur to learn from

them and to correct them. So I think those five things its roots If working feedback, incrementalism experimentation and empiricism are the Cornerstone of our ability, previous, a species to be able to learn effectively and efficiently. I can't imagine anything that we could consider to be engineering without those things. So the first third of the book is really about exploring.

Those ideas in much more detail in looking at each one of those principles and kind of picking apart and seeing how it fits with software development. I hope you enjoyed this short clip from pagli Journal favorite playlist. If you find this episode useful, please help. Share it with your friends and colleagues who you think would also benefit from listening to this episode.

And if you want to listen more from this conversation, please go back and listen to the original full conversation with my guest, stay tuned for the next technology, no episode. And until then goodbye.