 Right, so I thought, as somebody said earlier on today, I think keynot should be different to other kinds of talks. And I think that they should be leaving you with questions, they should be making you think about something. And I'm hoping that that's my keynot is going to do that. I want to talk about software engineering. I spent the early part of my career with job titles like software engineer or junior software engineer or senior software engineer or something like that. And if I'm honest, I did nothing that vaguely resembled engineering and not even close. And then in the middle of my career, a thought work was part of it, I started working for organisations that tended not to like the term engineering and reacted badly against it. We thought that engineering wasn't really describing what it is that we do. And then in the latter part of my career, I ended up doing something that took some serious engineering and I learnt some of the disciplines around that and had some remarkably different results. And so I'm starting to wonder about whether we should be thinking about trying to retake the language, take back the term software engineering, start to think of ourselves as engineers. And I don't mean by that some of the things that we thought about before. I want to plant the seed of a thought in your head. If we could come up with something that represented a discipline of software engineering for us, that should be as true in 100 years time as it is today. And if it's not that, it's not generally enough, it's not broad enough to cover what we're talking about. So try and keep that kind of thought in the back of your head while I talk about some of this stuff. So I think if you're anything like me, when people use the term software engineering, you think of something like this. And this is to software engineering, what a soldering iron is to electrical engineering. It's a tool. This is not engineering. This doesn't describe an engineering discipline. It's just a tool that you may or may not choose to apply. We're in an agile conference. You might think of something like this. You might think of process also as a tool and that defines our engineering practices. And I think that some processes a little bit more than others tend to do that. But nevertheless, this too is not an engineering discipline. In particular, Scrum says nothing about engineering. That's not what its focus is. Scrum is an excellent project management process and says nothing about engineering. It mentions the words code or software no times. And so it can't be talking about engineering. In the middle part of my career that I was talking about, when we started disliking the term engineering, one of the ideas that became increasingly popular was the idea of software craftspersonship. I'm trying to use a gender-neutral version. It's a bit ugly. It doesn't really work. But the idea that what we're doing is not engineering, it's a craft. And there's some good reasons for that, which I'm going to come back to. But I think this too, we can't consider craft the same as engineering. They're different things. So let's dig into those ideas and think about this a little bit. I would suggest that you can divide the history of human production of anything into three broad categories. I'm a bit of a reductionist, you can probably tell. The first one is craft. The vast majority of human experience was based on making everything as a craft-based process. That means that the quality is incredibly variable. It's going to depend on the level of the craftsmanship. I'm going to keep saying craftsmanship. Forgive me for it not being gender-neutral, but it's ugly to use the other pronoun. So it's going to be variable. It's going to depend on how skilled or dedicated or committed the craftsperson is. Later on, we tend to think of it as a 20th-century invention. It was actually a 19th-century invention. We started to introduce mass production. Mass production came along with the Industrial Revolution. The first mass production was an interesting thing. It was the creation of arms for the American Civil War. The American Civil War was a terrible, horrific war. One of the reasons it was so horrid was because they mass-produced the rifles that the soldiers used to kill each other. If you can have an interesting story about such a dreadful event, there's a story of the congressman, the man that wanted to get the contract to produce the arms going to Congress with a bag of components. He tipped the components out on the floor and asked the congressman to select components. From those components, he assembled a rifle. That's the first time in history that that was possible. Before that, every rifle, like everything else, was a hand-built work of craft. There were no interchangeable components. The standardisation of the pieces was a fundamental part of mass production. At the end of another war, at the end of the Second World War, Deming went to Japan and started introducing concepts that led the thinking along with some of the Japanese cultural things in the direction of what we now call lean production. Lean production has taken over much of the world of production because it's a scientifically validatable, reproducible, efficient process. I think these three categories pretty much cover what we're talking about. What are the characteristics of these categories? First, craft is art rather than science. There are no standards. Each piece of work is individually crafted and it's based on the expertise of the individual. It means that even for an expert individual, it's not really reproducible in the same way. Everything is going to be distinct and unique, every component that we create. Mass production is... We think of assembly lines and standardised components and being able to put them together. Following a standardised series of steps in management speak, we talk about tailorism, a form of management, to be able to divide people up and tell them what to do and make them components of the machine. Peace based metrics measure the efficiency of the process by how many bits we make and we have big warehouses to store all the bits because some bits are easier to make than other bits. It made a big difference in the efficiency of the process, the reproducibility of components. It was part of the thing that started driving the industrial revolution and allowed us to build cars and aeroplanes and stuff like that. And everything else of our society through the early part of the 20th century. Lean-based production techniques are somewhat different. They focus on quality at source. They're trying to divide work up into small steps. You can think of this as a pull-based system. If a mass production system is kind of push-based system, you're going to build components, you're going to push them down the line and then you're going to assemble things from those components until you've finished. A lean system is more like a pull-based system. You're going to pull those components just in time. You're going to have them just ready, just at the moment when we need them. And we're going to assemble things and move forward from there. Lean practitioners talk a lot about minimizing waste and making the processes efficient as possible. And they focus very heavily on autonomy of teams and decision-making in the teams to keep it all efficient and make it effective. There's another way at looking at all of this that I think is useful. And that's the idea as a process model. So that one discipline that is kind of expert at processes because that's part of their job is chemical engineering. And in chemical engineering they have a taxonomy of processes. They have different kinds of process control models that they recognize and describe because they apply them in different circumstances. I'm going to show you two from that. So here's one. This is the defined process model. The defined process control model requires that every piece of work be completely understood. Given a well-defined set of inputs, the same outputs are generated every time. A defined process can be started and allowed to run until completion with the same results every time. Hands up if you think that sounds like software development. Me neither. This is the world where mass production leaves, assembly lines and waterfall processes. A waterfall process is a good fit for those kinds of processes. The trouble is it's not our problem. That doesn't describe what it is that we do. Here's another one of these process control models. Empirical process model. The empirical model provides and exercises control through frequent inspection and adaption for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. Hands up if you think that sounds like our stuff. I think that's much closer to what it is that we do for a living. This space is inhabited by craft-based production techniques. I think this is one of the reasons why, in reaction to the big heavyweight waterfall processes of the 80s and 90s, people started going towards more craft-based working practices. It makes sense. It's a much better fit. It's a much more effective way of developing software than the really bad fit of trying to force fit a waterfall process onto a explorative exercise that is software development. But it has the problems that we talked about. It's also the space of exploration and continual improvement and lean process. So where are we? Where's the industry? We are not mass production and we are never going to be mass production because it's wrong. It's the wrong model. Mass production is about production. Our problem is not a production problem. Our problem is a design problem. It's a learning problem. It's an exercise in exploration. That's the nature of our game. I think it's fair to say that on the whole we are a craft-based industry. You can see that in the variable standards. We've all heard stories of one team doing loads better than another team and different technologies making a difference and that kind of stuff. There's a huge amount of variability. There's little standardisation in terms of the effectiveness and the quality of the output very often. I think that where we should be shooting for should be here. I think we should be thinking in terms of lean production techniques. I think this is a good kind of theoretical fit in terms of process for what it is that we're trying to do. Lean process is close to my heart because lean process was kind of grown out of trying to apply the scientific method to software development. I'm a nerd and one of my hobbies is reading about physics and I think that scientific method is the most important discovery that humanity has ever made. What do we see when we start applying that kind of thinking? When we start applying something that we might recognise, might think of as the application of more scientifically rational kind of thinking or engineering style thinking to our problem domain. What we see is quite dramatic changes in the productivity, effectiveness and quality of our output. We see ridiculous things. We see things like organisations that practice these kinds of disciplines make more money than organisations that don't. That's what the data says. So there's something here. There's something involved here. I've been talking about this kind of thing for a little while now. I've been exploring these ideas and if you get me drunk in a bar at some time, I'll bend your ear about what engineering means and I get involved in a surprisingly large number of conversations about bridges. People come up to me and say, yeah, but software development's not bridge building, is it? Well, no, it's not. But then I can say this because I'm a software developer, one of our failings as a profession is that we tend to oversimplify what everybody else does. Bridge building isn't what we think of as bridge building either. Bridge building is actually quite hard. And bridge building kind of divides up into two different separate parts of stuff. If you're building yet another boring metal suspension bridge, then you've probably got the recipe, you know what all the stresses are, you know what the designs and parameters are, there's a book somewhere you can look up the answers. That's one thing. Your huge problem when you're doing that is a production problem. You're building bridges out of physical stuff and you've got to get the stuff to the right place in time, you've got to buy it economically, you've got to make sure it can take the right stresses and all that kind of thing. That's your problem. Your problem is a production problem. But if you're designing a unique bridge, the first kind of a bridge that's ever been designed, let's say we're building the first carbon fibre bridge that goes across an ocean, that's going to be a very, very different kind of problem. That's going to involve creativity, it's going to involve experimentation. That's a design problem and that's our space. That's what we're talking about. That's much closer to what we're talking about. The other thing is that when we start looking at engineering, all engineering is not the same either. House building is different to bridge building. Chemical engineering is different to production engineering. Electrical engineering is different again. Space engineering, all of these things are different. They're also different in scale. Here are two different buildings. They are both engineered structures. I think it's absolutely self-evident that when you look at these, there's a difference in the amount of engineering that was involved in those two different structures. The one on the left, if that was built by a store that's selling sheds, then they're going to have engineered to be efficient in the use of materials and cheap to sell and build and a nicer kit that you can assemble your shed from, that kind of thing. It's still engineering, but it's going to be very, very different to the kind of engineering that goes to the building on the right, the Burd Khalifa, which is the world's tallest building. For that, somebody's been building models. They've been doing things in wind tunnel tests. They've been doing testing parts of the system to see whether it's strong enough. Material analysis, that's a design problem. That's a very, very different kind of problem. So engineering works at different scales. When we're talking about buildings, it's obvious the difference. Just looking at those pictures, anybody can tell the difference. When we're talking about software, maybe not so much. Is it obvious to a user of the system that my mom's cake shop website is trivially simple and Amazon is big and complicated? Or is it so obvious that the level of engineering that's applied in those different circumstances is going to be different? Probably not. But nevertheless, I would suggest that there should be some broad principles, some basic principles that are common themes in both of those cases. So what is engineering? And as I said, I've been talking about this for a while and occasionally I'll get involved in Twitter conversations and here's one of those Twitter conversations. I've blanked out in the person's name because I don't want to disrespect the person because I completely disagree with what that person said. I think that this is nonsense. For me, engineering means working in a certified and flexible process that includes planning a headlock and the antithesis of agile thinking. I'm sorry, I think that's nonsense. If you're building something for the first time, if you're facing this as a design problem, if you are Anita Sengupta who's talking later on in the conference and designing the parachute system for the Curiosity rover, nobody's ever done that before. Nobody's ever parachuted a spaceship through the atmosphere of Mars. You think that's following a plan and just the boring antithesis of agile? It's going to be discovery. It's going to be experimentation. It's going to be exploration. That's much closer to what we're talking about. Proper engineering, design engineering is much more similar to what it is that we do or at least I think it should be. So this is not engineering. So let's look at some definitions very quickly. Here's Wikipedia definition. Engineering is the application of mathematics, empirical evidence, scientific, economic, blah, blah, blah, blah, blah. Some descriptions, some common words tend to come up in definitions of engineering. My underline's too slow. Here's another definition. Again, the science of making practical applications, similar kind of words cropping up again. And here's another one. Scientific and mathematical principles applied to practical ends. There are some themes here in these definitions. So here's my working definition. This is what I'm talking about here. This is what I mean when I'm talking about engineering. Engineering is the application of an empirical scientific approach to finding efficient solutions to practical problems. And efficiency, I mean economic efficiency, production efficiency, environmental efficiency, whatever you care about. But all of those things are kind of part of the game. I would argue that if we're looking for something, that some ideas that are durable and are going to be true in 100 years' time, as well as now, there's probably going to be broad agreement in those sorts of ideas, I would imagine. And here's my five. I imagine that there are a few people that would disagree with these at some level. I think that if we're looking for an engineering approach, we've discovered that waterfall, big up front planning doesn't work. It's going to be iterative. It's going to be an exercise in discovery and exploration. In order to achieve that, it's vital that we have high quality, efficient feedback so that we can understand the impact of our decisions. It's going to be incremental. We're going to be building up systems piece by piece, step by step along the way. And it's going to be experimental. We're not going to know all of the answers when we begin. And we're not going to know all of the answers probably when we're finished either, but we're going to be learning all of the time. So we're going to be thinking in terms of experimentation and we're going to be carrying out experimentation throughout the process. And finally, it's going to be empirical. We're going to have to evaluate it in reality. We're going to have to go into production and understand that this stuff really worked ultimately because however strong our theoretical model is, it's never going to be perfect in terms of reality. So we're going to have to test our ideas against reality as well. So this is my starting point. This is my starting point for properties that I think will define an engineering approach or could define an engineering approach. So let's dig into those in a little bit more detail. We want it to be iterative. And again, I've gone to Wikipedia. Iteration is the act of repeating a process. The next bit is not very interesting, but with the aim of approaching a desired goal or target, it allows us to focus in, to hone in on an outcome. Iteration, iterative approaches are really important because it means that we can learn from our attempts. We can react to what it is that we observe and we can adapt based on what we've learned. I would suggest, if I was to try and capture, this is an agile conference, this is the agile thinking day, I would suggest that a good sound byte to sum up agile is inspect and adapt. It's about doing that pervasively everywhere. It's about trying to understand the reality of the situation, whatever the nature of that situation, and improving it, reacting to what we observe and making it better. Being iterative also allows us to steer towards a goal. If we were going to drive from here to, I don't know, Mumbai, we're not going to take a bearing where Mumbai is, steer the car and then just stick in that direction. We might have a plan, we might decide we're going to head off down a road and our plans probably are going to react if there's a problem on the roads, if the traffic is busy, which is always in Bangalore as far as I can tell, then we're going to react and we're going to change our direction, we're going to change our plan. That's important and working iteratively gives us the opportunity to do that kind of thing. It also means that it's being iterative that forms the basis for continual improvement. Several speakers throughout the day in the sessions that I've talked about have raised the idea of continual improvement. This is the gold dust, this is the magic, this is the difference between the real high-performing organisations and everybody else. The real high-performing organisations are the one that adapt and buy into this idea and process of continual improvement, looking to continually refine and improve whatever it is that they do. Being iterative also means that we get to get better and better and better and better at things that matter. By repeating things over and over again, we can improve our performance in each step. Feedback is the next thing on my list. Here's Wikipedia's definition. Feedback is information about actions and return to the source of the actions. Feedback means that we can observe the impact of our choices. We can understand what happened. It's kind of the information part of being iterative. You can be iterative without feedback, you'd be stupid, but you can, but enabling high-quality, fast feedback is a foundational principle for doing high-quality work, to my mind. My name is associated with continuous delivery and this is one of the schematics that I use to describe continuous delivery when I'm talking about it. This is all of that feedback. It's about the feedback loop from having an idea to getting that idea in the form of working software into the hands of users and understanding what they make of it. It's about the fast feedback loop of test-driven development and other forms of automated acceptance testing as part of the loop. But there's way more feedback loops than this. Continuous delivery is all about just optimising for fast-efficient feedback. Incremental, evolutionary design, continuous design, evolutive design, incremental design is directly related to modular design. Modular design is really important. My wife tells me that I'm a serial nerd, but she's wrong. I'm a parallel nerd. I can be a nerd on multiple fronts at one time. One of my nerdisms is I'm interested in aviation and the space programme and particularly the Apollo era space programme because I was a little boy when people landed on the moon and it just kind of catches my imagination. This is a Saturn V space rocket. This is a modular system. When they first designed it, designed it, had plans for the moonshots, they didn't have this kind of vehicle in mind. Their mental model was a bit like a Wallace and Gromit spaceship, if you've ever seen Wallace and Gromit, you have a spaceship that kind of takes off, flies all the way to the moon, lands on the moon, the people get out and walk around and get back in. It takes off and it flies back and lands on Earth. That's enormously efficient. It's enormously inflexible. It has to work, it has to do a whole bunch of different jobs and it has to do them all well. This is this bit of the spacecraft. I'll keep pointing here because that's where the screen usually is. This bit of the spacecraft is just to get the rest of the spacecraft from Earth to Earth orbit. That's a hard problem. You can see there's quite a lot of the spaceship that's taken up with that. The top part of the spaceship is composed of three principal parts. Here are two of them. This is the command module. The job of that piece was to get the astronauts from Earth orbit back to Earth. Then there's the service module. The job of the service module was to get the spacecraft, the whole assembly, from Earth orbit to lunar orbit and from lunar orbit back to Earth. This is the other part of the spacecraft. This is the lunar excursion module. This is the bit of the spacecraft that actually landed on the moon. This too is modular. This is in two parts. You've got the lunar ascent module, the top part. The job of that was to go from the moon to lunar orbit. The bottom part is the landing part. It goes from lunar orbit to land on the moon. Without this modular thinking, this would have been a much, much, much more difficult problem in energy terms, but also in production terms, being able to divide the problem up so that different teams could work on different parts of the system. This part of the spacecraft was built by an entirely different company to the service module and the command module, for example. It also meant that the system was composable. It meant that when things happened, you could recompose it and work it in different ways. You can use it in different ways. When the Apollo 13 disaster happened, if you've not seen that film, recommend it to you. A wonderful film, one of humanity's greatest stories. Their spaceship blew up on the way to the moon. They reconfigured the spaceship and they used this part, the lunar excursion module, as a lifeboat to get the astronauts back safely home. The other aspect of thinking in terms of modularity is that it reduces the batch size. Each piece becomes smaller and simpler, easier to reason about, easier, more focused on the job that it's doing, clearer to understand what's going on. I've used two different words that in English are very similar, iterative and incremental, and I've stolen this slide from my friend Jeff Patton. This is in his wonderful book, User Story Mapping, to just highlight the difference. This is an iterative approach. You start off with a rough sketch of what it is that you want, and then you fill in the detail until you get to the finished article. This is incremental. This is the modular approach. You build a part of it and you build that to production quality, and then you add more parts until you've got a whole. I think this little simple picture demonstrates the difference of what we're talking about. I think that we need both if we're going to do proper engineering, if we're going to build complex systems, we need to be able to do both of these things. We need to both work incrementally and iteratively. We need to be experimental. An experiment is a procedure carried out to support, refute or validate a hypothesis. They provide insight into cause and effect by demonstrating what outcome occurs when a particular factor is manipulated. I've adopted this as part of my working practices. When I talked earlier about applying some engineering thinking to some hard problems, I was involved in a project where we were building some very difficult high-performance software. We applied this kind of thinking. We just approached it from an experimental viewpoint and it just revolutionised the kinds of things that we could do and the quality of work that we were able to perform as a result. Being at experimental matters, and I want to tell you a little story to just try and paint a picture to explore that. This is John F. Kennedy, the 1960s American president, and in 1961, JFK stood up in Congress and said to the American public, we're going to send people to the moon and we're going to bring them back before the decade is out. And everybody at NASA went, because they had no clue how to do that. This was two weeks after Alan Shepard, who was the first American into space, had had his space shot. Alan Shepard was a remarkably brave man. What they did was they built a tin can, they strapped it on top of an intercontinental ballistic missile and they fired it 100 miles up and he parachuted back down in the tin can. Didn't go into orbit, that was the first American space shot. At this point, the redstone boosters that was the intercontinental ballistic missile were blowing up on the pad all of the time. So Alan Shepard, he sat on top of a bomb, fired 100 miles up and parachutes back down. A remarkably brave man. Two weeks later, Kennedy's saying, we're going to the moon and everybody's going, what? How do we do that? That's crazy. So Kennedy's just kind of positioned this idea. He's painted this picture. Somebody once said to me, is this the most expensive user story ever? And I think it's a shout. I think it's a good shout that it might be. So he's painted this vision of what needs to happen. Here are some pictures of the things that nobody knew how to do, which is quite a lot of the things that you need to know how to do. So, as I said, at this time, American spaceships were blowing up on the pad. Nobody launched a multi-stage vehicle yet. So you hadn't got that. Nobody got the splashdown sorted out properly yet. The next mission after Alan Shepard's, Gus Grisson went up and his space capsule sank and they had to rescue him by helicopter. Nobody had done a space walk. Nobody docked to spacecraft together. The Russians, nor the Americans, nobody. They hadn't really yet got spacesuits where you could move about. They got pressure suits from aviation, which would go to a certain altitude, but they hadn't got spacesuits where you could go on and do a space walk and move around. The mission control stuff, all of this stuff, they had no clue how to do. So how do you start with something on this sort of scale? One thing is that you start to apply some engineering thinking. This is Margaret Hamilton. This is the woman who first used the term software engineering. She defined the term and she was the lead for the spacecraft control systems that allowed people to land on the moon. So applying that kind of thinking is crucial. So here's a picture of the Earth-Moon system, except this is a kid's storybook picture of the Earth-Moon system. This is what it's like. This is a picture of the Earth-Moon system to scale. At this point in human history, no human artefact had been more than one pixel away from the Earth. That was the extent of our exploration to this point. So problem one, how do you get something from here all the way over there and back again? You can kind of imagine the day after Kennedy was stood up in Congress talking about this stuff, the meeting in NASA the next day. What do we do now? My brother-in-law's got a car show room, one could get a job there. I was like, oh no, what can we possibly do? I've got an idea, I've got an idea. Let's put three astronauts in a spaceship, send it to the moon and see if they come back. That's not a great idea, is it? No, that's not really going to work out. What are we going to do? I know I've got a better idea. Why don't we just send the spacecraft to the moon, bring it back without killing any astronauts? That's a step forward, that's an improvement. That's a better idea. We're starting to get a bit close to minimum viable products now, right? Hold on, I've got a really good idea. Why don't we just, for the first mission, send the spacecraft to the moon and land it on the moon? It doesn't have to come back. That nearly halves the problem. That's a terrific idea, that's a big step forward. Why don't we do that? What does landing on the moon mean? It doesn't have to survive the landing on the moon. That was the job of this spacecraft. This was the Ranger series of missions. This was literally spaceships as bullets fired to see if you could hit the moon. Because if you don't know how to do any of that, what's the point of trying to send people? So how did that go? Well, you might have predicted from what I said earlier, the first mission, it blew up on the pad. The second mission, the job of these two missions was only to get the Ranger spaceship into Earth orbit, blew up on the pad. If you've ever worked in a big project, you're going to like the next bit. The third one, they said, I know, let's go for the moon anyway. We haven't been able to get into orbit yet, but we'll go for the moon anyway. They did that, they got it into orbit. They'd learnt stuff from the first two. They did the de-orbit burn, shut off from the Earth and missed the moon completely. The fourth one, they got into orbit, they did the de-orbit burn. The spaceship died, it just died, but they managed to observe from Earth-based stations that it actually hit the moon. So they're learning things all along the way here. The fifth one missed the moon again. The sixth one, it worked. It got all the way to the moon, they got telemetry back, but the cameras failed, so no pictures. The seventh one, they worked, they got success. The eighth one was a success. The ninth one was a success. So your NASA, in the Cold War, effectively fighting out with Russians to win the race to the moon, you've been given this mission from the president. You've got almost an unlimited budget. The whole of the industrial armaments complex of America behind you. You've got access to the finest minds in the Western world. Could you imagine being at the end of a phone call, saying, hi, it's NASA here. We're having some problems, would you like to come and help us out? You'd be on the next flight. It would be so exciting. So you've got all of those things going for you. What do you do? You don't build a big ganchart. You don't do a big upfront design. You don't go and sit down, drawing pictures on pieces of paper for years. You start experimenting. There were millions more experiments than I just outlined. This is just a big story that I can kind of make a bit funny. But this is what you do when you solve, this is what human beings do when they solve world-class hard problems. They experiment. So let's try a little experiment. Here's an experiment. Here are two different pictures and there are two different orange dots. Can I have a show of hands if you think that the orange dot on the left-hand side is bigger? Can I have a show of hands if you think that the orange dot on the right-hand side is bigger? I think some of you've seen this before. Have a show of hands if you think the dots are the same size. Yeah, you've seen it before. It's an optical illusion that they're the same size. But we can carry out an experiment. So here's my experiment. I'm going to measure the dots. They are indeed the same size. Here's another one. Have you seen this one before as well? Yeah, so hands up if you think that the line on the left-hand side is longer. Nobody. Hands up if you think that the line on the right-hand side is longer. A few people. Hands up if you think that they're both the same. The majority of people who weren't paying attention because you can't know without carrying out an experiment. Here's my experiment. The line on the right is longer because I drew it longer. You can't tell. Without the experiment, you don't know the answer. Just guessing is not good enough. We need to be empirical. Being empirical is based on concern with or verifiable by observation and experience rather than theory or pure logic. We need to look to the real world. We need to look to reality. We need to look to production to learn. Being empirical also matters. It means that we can start making decisions on the basis of evidence rather than guesswork. We can start measuring things. We can start separating out myths from reality because we can test them and figure it out. We can start becoming more science. We can start applying real scientific thinking. One of the insights that I had not so long ago is that, first, we can never be certain of success. However many tests we have, how many experiments we carry out, until we go to reality, we don't know whether it's going to work. However many tests you have, you can never, ever prove that your software is good. But you have one test that fails and you know that it's not good enough. You can use falsifiability to do this kind of thing, but we can never be certain of success. We're always going to have things go wrong. Progress only comes when we risk failing. If we're not risking taking a chance and having an opportunity to fail, we're not really learning new things. We learn most when reality doesn't match our expectations. That's the point that we can kind of say, ah, well, we got that wrong, so now we've got to think again. We've got to think more carefully. Production is always going to surprise us, and it should, at some level, if it's not surprising us, we're not taking enough risks and we're not moving forward quickly enough. I think one way of thinking about this, that this is the kind of revelation that I had about a little over a year ago, I hadn't really thought of it this way before. But if you think about all of our design choices, all of the documentation, the code, the tests, the ideas in our head, the descriptions of our system, all they are is our understanding of what the users want. All of those things are only ever our best current theory for the system. And this is another lesson that we can learn from science. One of the most profound theories in physics is general relativity. General relativity is astoundingly accurate. It predicts everything from 10 to the minus 32 of a second after the big bang into the distant future and predicts what we see in space. We can run computer simulations that generate the cosmos from what we understand of that kind of model. And yet, we know that it's wrong because it doesn't quite fit with the other profound theory in physics that we have, which is quantum theory. So we know that it's wrong. So there are teams all around the world that are funded and tasked with trying to disprove general relativity and find out what's really the truth. We are the same. We are always explorers. We are always trying to understand more and more deeply, more profoundly what our software is, how it works, what it does, how to make it better and how to make it a better fit with our users, always. So all of these things are only ever our best theory so far and we should be looking at ways to improve them and refine them. So here are my five things. Fundamentals of an engineering approach. Actually, my favorite approach to software development is continuous delivery. And I think continuous delivery ticks some of the boxes. Ticks all of the boxes in terms of these five, at least, in terms of an engineering approach. It's iterative. It's absolutely iterative. We're going to go very quickly and make small changes frequently. It's focused primarily on making the feedback fast and efficient and high quality. It's incremental. It allows us to build modular systems and to compose them more effectively. Particularly if you start using techniques like test-driven development, that tends to move you in the direction of more modular code. It's experimental. We're trying that with ideas. We're not assuming that we know the answers. We're trying to learn. And the platform that continuous delivery provides and the mechanisms that underpin it, things like ideas like deployment pipelines, provide a wonderful experimental platform to allow us to try these ideas. And it's empirical. It closes the feedback loop into production so that we can learn and adapt based on what we find. It applies all of these sorts of techniques and so I think this is, it's a candidate. It's focused on these kinds of, these kind of feedback mechanisms. It should come as no surprise to you that fundamentally what I'm talking about is this. If you've got any kind of scientific training in your background, you're going to recognise this as a picture of the scientific method. This is humanity's best problem-solving technique. This is the thing that differentiates us from basically agrarian hunter-gatherer style civilisations to the modern high-tech world that we all inhabit. This is what did that. And when we apply this kind of technique to solving practical problems, we have a name for that. We call it engineering. Engineering is the difference. The engineering is the thing that's allowed our civilisation. We want to make an observation of reality. We're going to propose a theory based on what we observe. We're going to try and make a prediction based on that theory and we're going to validate that prediction with an experiment. That's it. That is humanity's best problem-solving technique. Without too much fear of contradiction, there's no data that says that anything else comes even close. Software development is one of the more difficult things that we as a species undertake. Shouldn't we be applying humanity's best problem-solving technique to that? We've learnt over the years, through getting it wrong quite a lot, that we need to do all of these things. We need to design, we need to develop, we need to test, we need to release software. But we've also learnt that these are continuous. These are not discrete phases. If we treat them as discrete phases, it's pretty much disastrous. So we want to develop our software processes, our approach to development, as a continuous process. We're going to iterate through all of these things all of the time. This is, again, quite a good description of continuous delivery, but I think more profoundly than that, it should be true of any engineering discipline that we undertake. In continuous delivery terms, we can talk about that as the cycle time, the distance between having an idea and getting working software out into the hands of users as one kind of measure. But what's important about this is really this. It allows us to carry out these, some of these experiments, it gives us a platform that allows us to validate some of our thinking, our ideas. We can have a theory, we can make a prediction, we can go out into the marketplace into production and we can validate those theories and understand what they mean. We can have a theory, we can make a prediction and we can design an experiment that we can carry out inside our test environments. We can have a bunch of automated tests that operate as a bunch of experiments that validate our thinking. All of these things are possible if we start applying this kind of thinking. This is quite a good description of continuous delivery, but I don't want to beat on continuous delivery because I'm talking about software engineering more than that now. I'm nearly at the end. You'll be pleased as I'm probably going to be overrun by a couple of minutes. But craftsmanship is a good thing. I sometimes get pushback of when I'm talking like this saying, yeah, but craftsmanship is really important. And it is. Craftsmanship is a really good thing. The ideas that craftspeople talk about are vitally important, skill, creativity, freedom to innovate, apprenticeship schemes, the innovation that these things drive are really vital to what we do. But this is just as true of engineering as it is of craft. We can replace the word craft with engineering and all of this is still true. So we can start to apply a little bit more discipline, a little bit more rigor in our approach and in our thinking, and we can start getting some of the benefits of an engineering-driven approach that enhance a craft-based approach, not replace it. Engineering adds to craft. It improves repeatability. It provides guidance and structure to our thinking and our processes and our production. It improves quality. It improves the efficiency of the process. And it gives us an approach to solving problems when we're stuck. When we're stuck, we go, oh. Okay, let's take a step back. What is it that we observe? What do we think that means? What's our theory? How would we test that theory? Let's try that and see what happens and find out whether our theory is good or not. So this is my closing slide pretty much. I'm not saying that this is an analogy. I'm not saying that this is a metaphor for software development. I'm not saying be like engineers. I'm suggesting that we should be engineers. We should adopt this kind of thinking. We should start thinking about what engineering really means for us and what we can get out of it. Thank you very much. Have a great conference. Thanks, Dave. Do we have any questions? We can take five minutes for questions. Anybody? Everybody wants to get out for the drinks, right? Hi. My question is the five ideas you have presented. Those are already part of the Scrum framework. So how different those ideas are? So I don't think... I would dispute that for one thing. Scrum doesn't say very much. It doesn't say anything about engineering, really. It doesn't say anything about being experimental. It's kind of implicitly there, but it doesn't call it out. So I'm talking specifically about carrying out experience and measuring things through automation. So Scrum, combined with extreme programming, I would agree with you. But Scrum alone is not sufficient to fill in these gaps. There's more to it than that. There's also... There's more to this kind of engineering model than this, I think. But it shouldn't be too detailed. Remember what I said at the outset? I think that if we came up with something, it should be as true in 100 years as it is today. And so it's got to be very general things. It's probably got to be stuff that we already know. So I think that there are probably some other things in the mix that would qualify these sorts of things. What I'm interested in is trying to socialise the ideas and just get other people's opinions and try and figure out what sorts of things we could use to define something that we could genuinely think of and start to put a bit of pressure on universities to teach. Start to think about applying some of these disciplines in our projects and so on. Thank you. When we talk about software engineering, it's been longed. When we talk about software engineering, either we are at very conceptual level of these principles or we are very deep down in terms of coding and coding practices. Where is that bridge that connects the two? So the five things that I've called out here, I think for me they seem generally applicable. I can't imagine doing high quality work in software development of any kind without involving those principles. There are some other ideas, things like modularity, separation of concerns, high cohesion, and more technical concerns that are important. I think that one of the ways in which previous attempts to define software engineering as a discipline have failed, the ways in which they've failed, is being too prescriptive. I think that they've tried to say, if you're not doing UML, you're not doing software engineering, if you're not doing design by contract, whatever it is, whatever the flavour is, and I don't think that's good enough, so I think we've got to look for these deeper principles. I think we've got to look for these more fundamental ideas. And as I said, I think that we would have fairly general agreement. Modularity and separation of concerns are good whatever the technical basis of the software that you're creating. That's good in functional programming, it's good in object-oriented programming, it's good with your rotten cobalt on a mainfro. All those things are ways of managing the complexity that is at the heart of our discipline. Dijkstra said that software development was nearly all about just trying to keep a handle on the complexity. We're trying to manage the complexity and keep a lid on it. And I very strongly identify with that, I think that's fundamentally what we're trying to do. And so trying to think of ways in which we can do that and things that we could start applying. One of the difficulties, one of the downsides of the success of agile thinking, I'm a card-carrying agilista, I've been a long-time agile person and applied that thinking to the project that I've worked on for the last 20 years, at least. But one of the downsides of agile thinking, I think, is that we've tended to throw out a bunch of ideas. There are some things that we can be proscriptive about. There are some things that we know don't work. If you want to build a big software system and you want to use waterfall, you are wrong. That's not really up for debate anymore. And if a team decides we're going to do a waterfall project because we like that, they're making a mistake. So I think that we should probably be a little bit more proscriptive. We should rule out some things that we figured out don't work and we should be open to things that we don't know and allows to evolve solutions to problems. Thank you. Anybody else? There's one right at the back. Sorry, there's a lady here first. How do we develop engineering mindset for the software developers? That's a great question and I think this is a generational thing. I think that this is not the kind of thing that we could flip a switch. And we're not going to get our generation, I'm probably a different generation to most of you here, but the people that are involved in this discipline today are not going to get all the answers. We're not going to come up with all the answers, but if we could come up with some principles that we could more broadly agree on and adopt and not leave it as an exercise for everybody to discover from scratch, that would be the starting point. I think we can start kind of talking about the ideas, we can start promoting them. I think we could... One of the things that at some point we're going to have to do is that our industry is going to have to engage more with universities and training courses. We need to do building apprenticeship programmes so that we can start guiding people to what I think of as... This sounds like a bad word, but a more disciplined approach to software development that's more effective. But it's a generational thing, it's not going to happen very quickly, it's going to take a long time. There was a gentleman at the back. Hi. I've managed electrical engineers before, and one of the big differences that I noticed between software developers and electrical engineers is the need for completeness in the psychology. Do you think that that also contributes that the psychology of who we are as people right now is really possibly holding us back? Yes, I do. I think that's a good observation. I think that one of the changes that I observed in myself is that I've become, as I've gained experience of working in these very agile ways, a very disciplined agile ways, that is the way that I think about it now, what I've found is that I am much more comfortable not knowing the answer to things. I'm much more confident to just start and just start down the route to discovery, and I'm going to get things wrong, we're going to go down the wrong paths, but that's fine, that's part of the learning exercise. I think, I was talking to Naresh in the break beforehand, I think that deeply what our discipline is entirely about learning and discovery. If we are not learning and we're not discovering, nothing else matters, nothing else is, that's the nature of what we do. If we're not building something for the first time, because production is essentially free for us, why don't we just take whatever it was off the shelf and use that? So we are always creating something new and that's an exercise in design and exploration and experimentation to my mind. And so we need to start getting that into the way that people think about things instead of say, instead of the big prediction things that you've got to have these features done by the end of the springs and we'll be tired you if you're not. We've got to think, we've got to allow things flexibility and time to be able to innovate and discover and learn and make mistakes, get things wrong. At Amazon, one of the things that I hear is that if 50% of their experiments are not failing, they up the level of the risk that they're taking in their experiments. It's important. Thank you.