Taking Back “Software Engineering”: Craftsmanship Is Not Enough

We're here today to talk about Software Engineering and what that means to us as a profession. That's really what I want to explore today.
In my own career, I spent the early parts of my career working in organizations with job titles like Software Engineer, Junior Software Engineer those sorts of things. And if I'm honest, during that period with stuff that I was doing bore very little relationship to any form of engineering that anybody outside of our profession would recognize. In the middle part of my career, I started getting jobs with organizations that didn't really like the term engineer so much and tended not to use the term Software Engineering. Instead they talked about ideas like just software developers, software craftsmanship - if you'll forgive the sexist nature of that term or the gender specific nature of that term. Again, we weren't really doing engineering, so that was probably a more accurate description during those days.
In the latter part of my career, I started working in some organizations that were genuinely doing some hard things. We were trying to solve problems that none of us had come across before and really pushed the boundaries of what computers could do in some narrow areas. And in those organizations, we started applying some approaches, some disciplines, I think now I'm more in line with what we might think of as engineering and again, those are ideas that I hope to explore today.
Let's start off with what tends to spring to mind when we're thinking about the term Software Engineering. And I think for many of us, certainly for me, the sort of thing that used to spring to my mind are pictures like this. This is not Software Engineering. This is to Software Engineering, what a soldering iron is to Electrical Engineering. It's a tool. It might be a good source. It might be a bad tool but it's only a tool. So, this doesn't describe what we mean when we're talking about Software Engineering. In other contexts, we might think about ideas like this. This is the idea of Scrum. This is a process. Development process, SDLC, as some people refer to it but it's really about the techniques and the procedures and the approaches that we apply to solving problems in software. Scrum is a very good project management exercise but have a guess how many times the documentation for Scrum mentioned the terms software or code. I'll give you the answer - zero times. It doesn't really talk in those terms. It's much more about project management. It's an effective project management strategy but it's as applicable to plumbing as it is to software development. This tool is not really a description of what we would think of as Software Engineering.
In more recent years, the idea of software craftsmanship has just come to the fore and craftsmanship, I think was an important step forward. I'm going to talk a little bit more about why I think that was the case shortly, but I think this was a step forward in recognizing that what we were doing wasn't Engineering and kind of by definition, software craftsmanship is not engineering. It's something else, it's craftsmanship and craftsmanship is a good thing. It's about creativity and so on. But if you think about craftsmanship, it's kind of limited to human scale effectiveness - creativity. Engineering tends to allow us to go beyond that. So, I'd like to explore that idea. One way of thinking about these things is to think about the history of producing things.
If you think about human beings making stuff since the dawn of time then pretty much all of our history, soft production of things has been based on craftsmanship. It's been based on the skills and the techniques of an individual to handcraft, some wheel, flint axe and cars, and so on but it wasn't until much later that we started learning different ways of undertaking those things. In the middle of the 19th century, the first steps in what we would think of as mass production began to take place. The first example of mass production was actually in the American Civil War. The man who wanted a contract to supply the rifles to the Northern States in that war, went into Congress with a bag full of components and he tipped the bag out onto the floor of Congress and asked the Congressman to select the components from which he assembled a rifle. That was the first time in history where that was possible. Up to that point, standardization of craft space production was not sufficient to allow the random selection of pieces and assembly of parts into a hall. The tolerances weren't good enough, each thing was individually handcrafted and was different than every other.
So, that was a big step forward and then through the early parts of the 20th century and latter part of the 20th century that effort was improved. Towards the latter half of the 20th century though, after the second world war the Deming went to Japan and introduced the ideas that ultimately ended up with the ideas of lean production. He worked with Japanese culture which had already had some of these ideas in place but essentially what Deming was doing was applying the scientific reasoning to solving problems in production and product development and that's really what his work was about. And that amplified the effectiveness and the art of being able to produce physical artifacts.
Now, there is an important problem. There's an important thing to recognize and we start thinking about these things. The history of our industry has been colored by humanities experience up to that point - perfectly understandably. And humanity experiences up to that point of producing things was nearly all to do with producing physical things. If we want to produce something physical or something like this pointer Then the design of this thing is a tricky problem but the really hard part is how do you make these things? How do you mass manufacture these things? How do you make these physical things? How do you make sure that you've got the right sorts of plastic in the right place at the right time, the right electronic components and so on and so on and so on. The production of physical things is a complicated problem. For software, that's a problem that we don't have at all. And so, the techniques that we apply for producing things in the real world are not directly applicable to software. Our problem is always a design problem. It's always only the problem of creating the ideas in the first place and we should be looking to optimize for that rather than for optimizing for the production of things. We've made this mistake in our industry profoundly and it's affected the way in which we think of, plan and undertake software development across the world.
The waterfall software development approach is really a production line fit way of thinking about solving problems and it's completely inapplicable to problems in software development. So, craft and mass production are certainly not what we're looking for. I think the advantage of a craft-based approach is that it's not making the mistake of assuming that we need the production line techniques to solve problems. And so, I think in reality, that's where most of the industry is at the moment. I think, where we should be aiming to be is lean production. We should be looking to use a more scientifically rigorous approach to solving problems and optimizing our processes and making those as efficient as we can through lean style techniques. When we start applying this kind of thinking to software development, the impact is profound. We see dramatic improvements in productivity quality and the impact that changes have on our user base. Users like the fruits of this kind of way of working. We are better able to hone in on what users need from us.
I've been having conversations like this about Software Engineering for a couple of years now and I get involved in lots of conversations with different people online through social media and at conferences and in pubs and new bars and one of the weird things about these kinds of conversations is I ended up having conversations about bridges quite a lot. I start talking about Software Engineering and describing my thoughts and people say, "Yes, but software isn't bridge-building." And I think, "Well. No, software isn't bridge-building." And bridge-building probably, isn't what we think of as bridge building either. Bridge building is going to be different. If you're building the hundredth version of a bog-standard steel and concrete suspension bridge versus the first ever version of some unknown kind of bridge. If we were going to try and build a carbon fiber bridge across the Atlantic that would be a completely different kind of exercise to building a hundreth versions of some kind of concrete and steel suspension bridge. It's not the difference between bridge-building and Software Engineering. It's to do with the novelty of the problem that we're trying to solve and this gets back to my point. It's the difference between Production Engineering and Design Engineering. If we're building that hundred concrete bridge, we've probably got a bill of materials. So, we've used 90 odd finds before and we can say precisely on what day we want, what volume of concrete in order to be able to make progress and so on and so on and so forth and if we are doing the first kind of a bridge forever, we're going to be doing all sorts of kind of research and exploration to understand what's really going on.
The other thing to say about bridge building is that bridge building isn't the same as house building. It's not the same as Aerospace Engineering. It's not the same as Chemical Engineering. It's not the same as any kind of engineering, each kind of each engineering discipline in different fields is tailored to that discipline. It's different in different contexts. So, one of the things that we can be certain of is that where were we to come up with a genuine engineering discipline for software, it will be ours and there will be attributes of it that were unique to us. It would be about creating software and not be about building bridges but that doesn't reduce the impact of applying engineering style thinking to software development.
There's another way in which engineering is different in different contexts. It's different in different scales. In these pictures here, I'm showing you how to build structures to engineered structures. The one on the left is a shed. If this was built by Ikea, you can bet that they would have engineered it to its bottom dollar in order to be able to drive cost down and make sure that he's in the minimum materials to make it cost effective to sell sheds at a good price. On the other hand, if you're looking at the building on the right, that's the tallest building in the world, the Burj Khalifa. And if you're creating a building like that, you're going to be doing exploration. You're going to be building models and wind tunnels, doing finite element analysis on the structures and you're going to do experiments to measure the tensile strength of particular kinds of materials and all of that kind of stuff. These are very, very different. This is absolutely clear. This is self-evident when we look at something like a building or two buildings in this case but it's less evidence if we look at two different pieces of software, certainly not to the layman. If we look at, I don't know, the software that sells cakes for my mother's cake shop versus the software that flies an airplane control system. We would expect there to be different levels of engineering involved in those two different cases but there should probably also be a level of commonality. There's going to be more rigor in one case than the other because the consequences of it going wrong are higher in one case than the other. Nevertheless, if we're looking at being effective and efficient and doing each one in an efficient manner then there are going to be these common behaviors that they're going to work in every software development case. Those are the things that I'm kind of interested in.
So, let's start thinking in terms of definitions and here there's a definition from Wikipedia which describes engineering and it mentions a bunch of words. And these words tend to crop up in the definition of engineering. It's about scientific reasoning. It’s about applying mathematical thinking. It's about using evidence-based decision making and it's about working within economic constraints. For the purposes of the rest of my talk, this is the definition that I'm going to use. This is my definition of what I'm talking about. Engineering is the application of an empirical scientific approach to finding efficient solutions to practical problems. If you think about that definition, each of those words is important. Each of those words is something that we can't do without it. If we've got to think in terms of Engineering, we're trying to make evidence-based decisions. We're going to be reasonable and the economics of the situation are part of the game. We're trying to do things to a certain cost and that's in terms of performance or price or whatever else. I think when we start thinking in these sorts of terms, we start thinking about these profound terms of what engineering really means. It kind of breaks down into two different groups of problems. I had a conversation with somebody via social media a little while ago and that person said something profound to me that that really resonated with me. They said that if we were able to identify some principles for software engineering, those principles would be as true in a hundred years’ time as they are today. And I think that's correct. The things that we're talking about here are foundational, fundamental, those should be the grand - the building blocks of our discipline. Again, following that though, that line of thought, I think that engineering breaks down really into Software Engineering that is perhaps down into too many problems. First, we need to be able to manage the complexity of a problem. We need to be able to put a cap on how complex the pieces that we are working on so that we can fit them inside a human head. This modern software is vast and complicated and many systems are beyond the realm of any one person understanding them fully and so we need to apply ideas like modularity and separation of concerns and information hiding and cohesion and all of those kinds of software, computer science-y terms that describe the approaches to development our foundation or to an engineering discipline to allow us to make progress.
The other aspect though, I want to spend most of today, the rest of today talking about is really about optimizing for learning. If we are working in a discipline that is focused on design and creating innovative solutions to the problems that we undertake then our discipline, our problem is nearly all about trying to learn. It's exploratory. We're trying to discover what the problem really is that we're trying to solve. We're trying to discover how we can apply the techniques of software to solve and address those kinds of problems and we're trying to learn how to effectively use the tools, the technologies at our disposal to fulfill those needs. So, it's nearly all of that learning and that's where these 5 things come in.
I think it's impossible for me to imagine any kind of engineering discipline in software that doesn't embody these five principles. It needs to be iterative. Our approach needs to be iterative. We need to employ feedback. We need to be incremental so we can make step-wise progress. We need to be experimental. We need to be able to try ideas out and discover the things that work and the things that don't. And we need to be empirical. We need to react to what happens in production and really in the live situation what's going on.
So, let's go through those as a bit more detail. Being iterative is important, iteration is at the heart of our ability to learn and to deepen and evolve our understanding over time. The sense in which I'm thinking about iteration here specifically is being iterative and navigate towards an outcome but there are many positive aspects to working in an iterative way. Being iterative is deeply important to agile thinking because it allows us to learn from something. We can react to what it is that we learn and we can adapt our approaches, thinking processes, technology designed to fulfill the needs that we've now noticed through learning. This is a powerful approach to solving problems. Being iterative also allows us to navigate towards some desired outcome. If we've got a goal in mind, we can figure out where that goal is and then we can keep reflecting on whether the things that we are doing, is moving closest to that goal, or further away from that goal. Even with something as seemingly straightforward as sailing a boat from Copenhagen to Oslo. The captain does not naively take a bearing from Copenhagen and Oslo and stick to that come what may, that doesn't work. In the real world, there are things that will push the ship off course, the winds and the tides will change the outcome and so that the planning needs to take part of that. Traffic will be along the way. We need some reactive planning to be able to adapt to what we're doing as we learn new information, as we gather new information and that's what iteration allows us to do. Iteration also allows us to improve things over time. Step-by-step we can get a better and better outcome as we learn more and more and more about the products that we create, the techniques that we use and so on. We can refine that it was fun to get, to get a more effective solution. Being iterative also allows us the opportunity to enhance our own skills, our own learning, our own understanding and our own technique as well. It's the kind of at the root of any process of continuous improvement.
The next in my list of five things is feedback. A feedback is the technical definition is information return to the source of an action and feedback is kind of at the heart of modern software development. Feedback allows us to reflect on what it is that we've done to observe the outcomes of our decisions. And again, feedback combined with iteration allows us to then refine those decisions over time. When I speak about continuous delivery, I often use this model to describe what I'm talking about. This is a simplistic view of continuous delivery. There are many more feedback loops involved in this, these other three primary continuous delivery feedback loops and the outside, we have the feedback loop, have an idea, get some working software into production, figure out what our users make out of those ideas. The inside, we have the tight feedback loop of test-driven development and in between you have executable specifications and acceptance test driven development. These for me are what define continuous delivery and so it's a feedback driven approach.
The next thing, my list of five things is incremental. Incrementalism is about modular design and thinking of ways in which we can cut and break the design into a series of pieces so that we can concentrate on those pieces. Send me independently of one another. My wife describes me as a serial nerd and she's not quite right. I'm a parallel nerd. I can be a nerd on multiple fronts at the same time and I'm going to demonstrate that to you now abide by exploring one of my notions which is software engineering and software development with an example from another which is aerospace and particularly that space exploration.
In this picture, I'm showing you a picture of the Satin 5 Space Rocket. This is the machine that took astronauts from the Earth to the moon and brought them safely home again. This was a modular design and that wasn't the way that NASA started out thinking about this but it was a profound step in the advancement of the Apollo program when they realized that that'd becoming a modular design was important to them. In this diagram, there are two course grade modules that are visible. The first part is the Satin 5 itself. The job of that part of the spacecraft was to get the rest of the spaceship into Earth orbit. That's a dramatically difficult problem to get all of that mass out of the gravity well of Earth and so it takes all of this rocketry and fuel to achieve that. The rest of the spacecraft was he saying between four pieces, four modules. Here are two of them. This is the command module and the service module. The command module was responsible for getting the astronauts from Earth orbit back down to Earth. It was also the place where they lived for most of the time trip but its primary job was to get them safely back to Earth again. The second part is the service module and its job was to get the spacecraft from Earth orbit to the moon and from the moon back to Earth orbit again. There are two other modules that were involved in the process of getting men to the moon. These two, this is the lunar excursion module. The top part of the lunar excursion module is the lunar asset module. And its job was to get two astronauts from the surface of the moon back into lunar orbit. So, they could rendezvous with the command and service modules where a third astronaut was waiting for them. The bottom part of the lunar excursion module was designed to get the two pieces to the surface of the moon. So, from lunar orbit to the surface of the moon. This was important.
The modularity is a number of benefits. First, it allows you to decompose the problem. In this case, when NASA was constructing the spacecraft, they were able to farm out the jobs creating these different modules to completely different firms. By defining the interfaces between the pieces, they were able to give one company the job of building the lunar excursion module. Another company, the command module, and another company, the service module, and so on and so on. This meant that work could be done parallel and so it could be done more efficiently. It also gives you the flexibility to compose the system in different ways later on. So, when the Apollo 13 accident happened and the service module, part of the service module exploded damaging systems throughout the spacecraft, the astronauts were able to reconfigure the system and use the lunar excursion module, the ascent module as a lifeboat and against original plans where they would have discarded that in lunar orbit instead they kept the ascent module and traveled back to Earth in the ascent module as a lifeboat and this saved their lives. This flexibility is another of these fundamental properties of incremental design.
I've used two words that end in the English language that are very similar. It may be confusing and this is the best way I know of disambiguating those two terms. I've stolen this from a real good friend of mine, Jeff Patton, who uses them in this great book: User Story Mapping. So, being iterative is demonstrated in this picture. We work in a way; we start off with a rough sketch of the system that we intend to get to and then over time we refine and refill in detail until we get some sort of outcome that we're satisfied with. The second pictures show what incremental means in this approach, we're going to divide the system into a series of pieces and components and each of those pieces can develop can be independent of the others but maybe even iteratively but the system as a whole is not assembled and until you've got all of the pieces. I can't imagine any software engineering approach that doesn't involve being both iterative and incremental. We need both of these techniques in order to make high quality complex systems.
The fourth of my properties as a software engineer is being experimental. Being experimental is profoundly important. This is about carrying out evaluations of something and controlling the variables so that we can learn some lessons. One of my other nerdy-isms is that I'm an avid reader of popular science and so experimentation is very close to my heart but I think it's profoundly important in the effectiveness and efficiency of organizations.
Amazon are a great example of this. Jeff beats his own record of saying that the level of risk that an organization should just scale up with the size of the organization. Amazon goes to the extent of tracking each of their experiments in production. If 50% of their experiments are not failing, they up the level of risk that they're taking because they need some of the experiments to fail in order to learn. One of the profoundly important attributes of the scientific method is that we learn more when an experiment fails than when it succeeds. It's kind of a superpower of the scientific method. Being experimental is important that I want to use another Apollo story to kind of outline that.
In 1961, president John F. Kennedy stood up in Congress and he just made his famous speech in which he said, "We're going to send people to the moon by the end of the decade and get them safely home." At this point, everybody in NASA took a deep breath and panicked because they had no clue about how to do this. At this point in history, this was in 1961 and this was two weeks after the first American made it into space. American was called Alan Shepherd and Alan Shepard was a ridiculously brave man. Alan Shepherd’s space trip was essentially him sitting in a tin can, strapped on top of an Intercontinental ballistic missile launched a hundred miles up and then back down the duration his trip was measured in minutes and the risks were enormous. At this point, the Redstone rocket that they use to launch the vehicle was commonly blowing up on the pad. So, I went to Shepherd, who was taking his life in his hands. He's launched a hundred miles of parachutes back down. Two weeks later, Kennedy said, we're going to the moon. So, Kennedy's kind of done what leaders do. He kind of had this vision and he planted a flag and said, "Let's do this remarkable thing. I'm a politician. I have no idea how to achieve this remarkable thing your engineer's sort it out." He had this vision. He's come up with this idea. Somebody once said to me, "Do I think that this is the most expensive user story of all time?" And I think it's a good candidate.
So, he's come up with these user stories, come up with this vision for what's going on. In this picture, I'm showing you examples of the stuff that at the point, when he made his speech, NASA didn't have answers for. So, they hadn't really got launches sorted out. At this point, if you look at a montage of the American space industry at this point, their launches, they were blowing up on the pad all of the time. They hadn't done multi-stage view launches yet. They haven't got the splashdown correct. The following mission after Alan Shepard was Gus Grissom and when he landed back, he also did several orbital hops splashed down in the Atlantic and his capsule sank and he nearly drowned in the process. Nobody had yet docked spacecraft together. Essential if you're going to do the lunar rendezvous approach, the modular approach to systems that we talked about before. Nobody has yet done a spacewalk. I need to be able to spacewalk, in case of emergencies to correct the system, but also to learn what it took to have space suits. I moved about when so the astronauts could walk on the moon, nobody had done that. None of this stuff was in place at the point at which Kennedy made his speech.
So, where do you start, you know, under the circumstances where you even begin to think about solving problems like this? Well, the first one is that you hire some really smart people. This is a picture of Margaret Helton, who was the first software engineer. She was the person that defined the term software engineering. Margaret led the team that was responsible for the flight control systems on the Apollo missions and she came to realize that the sorts of things that they were doing was engineering. They were thinking about the ways in which things could go wrong and they were approaching things with a much more disciplined approach to solving problems. But that too isn't enough. Here is a picture of the Earth-Moon system. So, it’s important to understand the nature of the problem that you're going to tackle, except this isn't the nature of the problem that they were tackling. This isn't a picture of the immune system. This is a kid storybook picture of the Earth-Moon system. Here is a picture of the Earth-Moon system to scale. At this point in human history, no human being, no human artifacts had been more than one pixel away from the Earth. They were nowhere in terms of space exploration at this point. So, the first problem is how do you get from the Earth all the way to the moon and back again? It's an enormous problem. You can kind of imagine the NASA engineers sitting in NASA headquarters afterwards trying to figure out what to do. "Oh, no. What are we going to do? He said, we've got to go to the moon in nine years. How are we going to do this? Oh, my brothers-in-law got a car showroom. Maybe we could get jobs there. No. Now, let's try and solve the problem. What's the problem? We can't solve it. I know let's build a spaceship. Let's put three astronauts in it. Send them to the moon and see if they come back. No, no, no, this, this isn't the room. This isn't the place for waterfall thinking. How do we solve this problem? How do we make the problem less risky? I know. I know why we don't we build a spaceship, don't put any astronauts in it, send it to the moon and see if it comes back again. Well, that's better. We might keep our funding for a bit longer. We're not going to kill a few astronauts. That's definitely an improvement but it's enormously difficult getting something all the way to the moon and back again. It's hugely difficult. Oh, I've got a great idea. Why don't we just send the spaceship to the moon and land on the moon? That is a great idea that nearly halved the problem. We'd know loads more after we could do that. That would be a really big step forward. What does landing on the moon take? What does landing on the moon mean?" It doesn't have to survive the landing on the moon. And that was the job of this program. This is the Ranger Program and the Ranger missions were designing, literally, spaceships as bullets so that they could carry at target practice. They're going to fire these spaceships at the moon to see if they could hit the moon. That's what this spaceship was for.
The first step of least the first objective though, they're kind of the minimum viable product of space or hitting the moon is can you get this thing into orbit and guess what? It blew up on the pad. It didn't work. So, then the next mission was also focused on getting the spaceship into Earth orbit. That also failed. It blew up on the pad. If you've ever worked in a big project and seen project management working in those sorts of environments, this next one might amuse you. They've just failed on launch for the first to the next mission was supposed to go to the moon. So, they wait from the moon anyway. In reality, they had learned things from the first two emissions although they were a failure and so they did make it into orbit this time. They did manage to do the deorbit burn and shoot the ranger off towards the moon and they missed it entirely. The fourth mission was a success. The spaceship got into Earth orbit. They did the deorbit burn it, headed off from the moon especially then died on its way to the moon. From Earth based tracking, they managed to observe it hit the moon so that was a step forward. The fifth one missed the moon again. The sixth one, it worked. It got into Earth orbit, headed off to the moon, hit the moon. It got telemetry back, the cameras failed but they'd still learn more and they've made it more progress. The seventh mission was a success. The eighth mission was a success and the ninth mission were a success.
So, NASA, in the cold war, you've got an essence and unlimited budgets. You've got access to the finest scientific and engineering minds in the Western world. Can you imagine by the end of the phone call at that time is, "Hello, this is NASA. Would you like to help us send people to the moon? Because we're stuck. You'd be on the next plane. At least I'd be on the next plane. If you got that phone call. So, they've got access to almost anybody that they needed to solve these problems. Where do you start? You don't start by forming a detailed plan and drawing out charts again and figuring out who's going to be doing what in nine years’ time. You start trying to figure out how you're going to learn. You start trying to figure out what tests, what experiments should I undertake in order to gain more information, deeper understanding. So, I'm more likely to get a successful outcome with this mission. And that's what the Ranger Programme was about. This was one of millions of experiments that NASA carried out to do this period. They were that the experiments range from complex ones like I'm talking about two simpler ones, measuring the tensile strength of a particular component of the system or a bolt or something like that. The home Apollo program was designed as a series of experiments, focused on learning. One of the other huge advantages for the modular approach to spacecraft design and systems design in general was that you didn't have to have all of the pieces to make progress. So, the early Apollo missions did not have lunar modules because the lunar module wasn't finished yet. So, they were able to make progress, test out other parts systems of the aircraft, and get feedback. This is kind of the minimum viable product for spaceships.
Being experimental allows us to make progress. It allows us to build on our learning. Here's a simple example of how important experimental technique is to me. In this picture, there are two orange dots, which one's bigger? I often do this as an audience participation gang where I ask people to give a show of hands. That's not very practical at the moment. So, just barely in mind which is your answer. Are the dots on the left-hand side bigger or if the dots on the right-hand side bigger, or are they both the same size? We can find out the answer to that by carrying out an experiment. If you guessed that they were both the same size, you've probably seen something like this before and it's an optical illusion that the kind of falses our senses. Here’s another one of those kinds of things. So, which line is longer? Is the line on the left longer or is it in the line on the right longer or are they both the same? If you've seen this before, you've probably guessed that they're both the same. In this case, you're wrong. They're not both the same because I made the line on the right longer on purpose. You can't know the answers to that question without carrying out the experiment just guessing is not good enough. Being experimental is about making a prediction and then evaluating the accuracy of that prediction. Whether the experiment passes or fails, we're able to learn from the results and that's deeply important.
The last of my five principles for software engineering is about being empirical and empiricism is about learning from reality rather than prediction or theory. Being empirical matters a great deal particularly in the field of software. We have to make judgements, predictions about the way in which our software is going to operate in production but it's very hard to get those right. The only accurate answer is to evaluate these things in production and measure the result. But the empirical matters because it allows us to make evidence-based decisions rather than theory based or guesswork based decisions. It allows us to separate myth from reality and it allows us to move forwards and do research and to grow and deepen our understanding step-by-step. Again, this is part of more scientific, rational approaches to problem solving.
The empirical matters because we can never be certain of success. We can never be sure that our ideas are the right ones until we get feedback and understand that our ideas have landed or effective or how the designs work. That's the time when we know that this is true, truly the case. Progress only comes when we risk failure, we must take the risk and therefore we must work in a way that allows us to collect evidence, data, you just see information. Feedback and then the lesson to learn from production and from the real use of that software. We learn the most when our predictions don't match reality. Again, this is the power of the scientific method. The ability to work in a way where we can make these predictions and then test those predictions and learn whether they're right or wrong. In both circumstances, we're able to make progress. Production is always going to surprise us and if we are taking the kinds of risks that we are talking about in working in an experimental way then it should surprise us. A good way of thinking about this is I think is if you think about all of the information that we hold about the software that we're working on, our mental model of what it is that we're trying to achieve, our mental model of the design. The design itself, the source code of our software, the test that we run against it, the way in which we organize ourselves. Everything to do with the software and now the products that we create is really only ever our best theory of what's going on so far. If we're going to work in a genuinely rational approach then what we should be looking for is to evaluate those series and test those theories and understand how to get better over and over again.
This is really the theory of continuous improvement and this is it's fundamental to a scientific approach to reasoning. If you think about modern physics, the two cornerstones of modern physics are quantum field theory and general relativity. These are deeply profound ideas that inform our understanding. Beyond any other human experience in terms of the accuracy of their predictive models and yet we know that they are incompatible with one another and so one of them is mistaken. It looks like it's probably general relativity. It looks like general relativities is a theory on top of a different level of abstraction than quantum field theory but we don't really know and there are teams funded all around the world to dig into and try and refine and come up with newer, better theories to answer these questions. We should be thinking in those sorts of terms. We never really done with software until the software is out of commission. Up until that point, we're always refining and improving and developing our theories of the system and that is an effective way of working.
I got into talking about software engineering really via continuous delivery. And that's a result of working in continuous delivery and teaching people how to use continuous delivery to help them with their software development needs and realizing that there was something going on here. There were some profound reasons why these stuffs was working. Continuous delivery is an approach that's grounded in the kind of scientific thinking that I'm talking about. It's based on short, tight, high quality feedback cycles. It uses test driven development in which we create these little tiny experiments that populate tiny universes that make our software so that it can control all the variables so we can evaluate that code. People uses automation to limit the variables so that we can understand the impacts of changes and we can control things and get reliable outcomes. It uses a hypothesis driven development where we're going to make predictions about the kinds of ways in which our products will land with our users and then we can test those predictions in production. And it uses test as a false indication mechanism to disprove our systems rather than to try and attempt to prove them. These are binds inspired ideas. It's also based, as I said before, profoundly on the ideas of feedback and optimizing for highly efficient, high quality feedback.
Fundamentally though, this is what software development, software engineering is about. We need to be working in a way so we can make an observation. We can observe whatever it is that we're looking at. We can propose a theory based on that observation. You make a prediction from that theory and then we carry out an experiment to validate to that theory. These predictions, observations, experiments are happening at different scales that can be product level, they can be code level. But nevertheless, trying to close those feedback loops and working in this more scientifically rational way is the way that we get to unlock those benefits that I spoke about earlier in the presentation in terms of the quality, speed and accuracy of the systems that we are able to create.
When we talk about software development, we often talk in terms of analogies, we talk about our software development being like the movie industry or like bridge building or whatever else. I'm not doing that today. I'm not talking in an analogy. I'm not saying let's be like engineers. I'm let's say, "Let's be engineers. Let's start applying the kind of scientific reasoning that leverages human creativity and amplifies it and applying that to the very difficult problem with software development."
Thank you very much indeed for your time today. I hope you have a great day.
Thank you. Bye bye.