Beth eich cyfnodau yn gweithio'r pwg yn eich hwn, gallwn i'n eich bwmpfa yma o'r dynnu at eich welfyn. Fe hwnnw wedi gweld o hynny, oherwydd ar hyn yn y sphwyr yma yma eich rheswm oes y dynnu ymen, ydydd y fferm yw'r enghraifft yn gwneud eich wneud eich arna arnyn. Mae ar gweithio'r gwrth o'i ch annid eich rhan arnyn nhw, during the early parts of my career. And then through much of this century, that's kinda become a little bit unfashionable. It's a soft, thinking about it, the software engineering has not been appealing. And I can understand the reasons for that. I think there are good reasons for that, which some of which we'll talk about. And the craftsmanship movement has come up. And I don't think there's anything evil about the craftsmanship movement. I think that craft is important, but I think it's not enough. And I wanna try and make the point and talk a little bit about what that is. I think in recent years, the last decade, maybe the last 15 years, we started learning some things about software development that we didn't really know before, at least we didn't apply regularly before. That has made a step change in capability in terms of being able to deliver software more effectively at higher quality. That's in part when I think about it because we're applying more engineering style thinking to the development of software. That's my thesis. That's what I want to talk about this evening. I think when we think about engineering, often we think about things like this. This is to software engineering what a soldering iron is to electrical engineering. They're not the same thing. This is not engineering. This is a tool. It may be useful in applying some engineering, or it may not. It's a tool, but it certainly doesn't define what software engineering should be. We might think about the processes behind our software development. We can think about Scrum and those sorts of management processes. Anybody, any idea how many times the documentation, the guide for Scrum mentions the word software or code?  It is zero. It mentions it zero times. Scrum is a very good project management discipline that is equally applicable to plumbing as it is to software development. It says nothing really about software development on its own. Without the engineering disciplines that we need to apply to add on to it, it's not an engineering discipline. In recent years, craftsmanship has an idea. Software craftsmanship has gained ground. Apart from the sexism inherent in the name, that's a different argument which I'm not going to go into. I think this too is not enough. This is not engineering either. Craftsmanship is not the same as engineering and I'm going to go into a little bit more detail of what I mean by that. I think an interesting way of thinking about this is to think about the history of human production. This is probably a gross simplification but at least at the level of my gross simplification, I think that there are three levels of the production of things that humanity has seen. For much of human history, everything that we created was the result of a craft-based process. Everything was hand-built. It was down to the work of individual artisans and the quality was very variable. We then moved on to the era of mass production about 150 years ago with the first instances of mass production where we started making things more reliably. Then at the end of the Second World War, Edward Deming went to Japan because the Americans weren't listening to him to try to help revive the Japanese economy. The thoughts that he started off grew and developed into the Toyota process and the lean movement. Lean production techniques has taken over the world in high-tech production, certainly, but in production across the board, really. Let's look at each of those in a little bit more detail. The history of production for craft is craft-based art rather than science. It's about the individual skills of an individual person. There are no work standards. It depends on the quality of work of a person. Each piece of work is unique. It's handcrafted. That's kind of what it means. It's based on individual expertise, so the quality is extremely variable. I think that, on the whole, we have a fairly romantic view of what craftsmanship is. We think of it as being a nice thing. If you buy a very posh car, you might have hand-stitched leather seats or something like that. On the whole, craftsmanship is characterised by being low quality. Imagine, for a moment, just to paint the picture of what I'm talking about, imagine a hand-crafted iPhone. It's a nonsense. It makes no sense at all the idea of something like that being crafted. That's not possible even as a prototype without engineering. The history of mass production is a little bit older than we think. We tend to think about assembly lines in Henry Ford building cars and so on. The first real mass production was, unfortunately, production of armaments in the Civil War in America. There's a nice story, if you can have nice stories about building things to kill people, but there's a story about the man who wanted to try and get the contract to supply the northern states in the American Civil War with their rifles. He went to Congress with a bag of components and tipped them out on the floor of Congress and asked the congressman to select the different components from which he assembled a rifle. That was the first time when there was such standardisation of components to allow for that. He won the contract as a result. Somebody told me that he was cheating when he did that. Prior to that, each rifle would have been hand-built by a craftsman of some kind. Certainly in previous wars, even to the extent that you were given a mould for the bullets for your gun, if you broke your gun you took it back to the person that had built it originally very often. These were individual things. The standardisation revolutionised the ability to, in this case, wage warfare. Later on, Henry Ford came along and came up with assembly lines and so on. Let's be clear, mass production is a big step-on in terms of the ability to repeatedly produce quality artefacts. Mass production is about assembly lines, standardised components, standardised steps in the process of creating things. Peace-based metrics. We measure the progress of a mass production process by how many components we've created. Then we move on to lean production. Lean production is about this focus on quality, quality at source, build quality into the things that we're creating. It's about pull-based systems. If you think about mass production systems, you're building components and effectively you're pushing them down the line.  For lean production, that's more like a pull-based process. We have ideas like just-in-time delivery, just-in-time manufacture, just-in-time warehousing. We're going to pull the things just at the moment when we need them and we're going to try and keep the whole process lean and efficient as a result. We're going to minimise the amount of work in progress. We're going to focus on minimising waste in the system. There are ideas like one-piece flow that come into play in lean-based manufacturing. Where does this apply? What do these things mean? One of the disciplines that is fairly rigorous in looking at processes and approaches to solving problems is chemical engineering. By the nature of the job of chemical engineers who are trying to industrialise a production process for building some material of some kind, they're very interested in the nature of different processes and they have a taxonomy for process control. Here's one of the process control models that they talk about. 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. The first thing that I would say about that sounds nothing like any software development that you've ever seen in your life. The kind of approaches that play in this world are mass-production assembly lines and waterfall processes. This is one of the reasons why waterfall processes are such a terrible fit for software development. It's because they assume that everything's kind of a cookie-cutter, a production process. The chemical engineers have another process control model that's kind of interesting. It's called the empirical process control model. The empirical model of process control provides an exercise of control through the frequent inspection and adaption for processes that are imperfectly defined and generate unrepeatable and unpredictable outputs. To me, that sounds an awful lot more like what my life feels like when I'm writing software. That feels much closer to the sorts of problems that we day-to-day try to solve. This is the territory of craft-based production, exploration, continual improvement and lean process. One of the reasons I think that the idea of software craftsmanship has gained such ground and has such appeal is because it is a significantly better fit than a waterfall-style process. In reaction to the waterfall processes that we mistakenly employed through the 1980s and 1990s, we reacted against that. That's when the idea of software engineering started to be a bad name. We came up with the idea of craftsmanship. That's a better solution. It's a better fit for the kind of process that we're talking about. But I don't think it's good enough. I think that what we should be aiming for is much closer to a genuine lean process. Where is the software industry right now? I think it's not anywhere near mass production. I think it never will be. If it was, it would be a disaster. It's the wrong type of model. I think this is where software development is. We see this in the variability of quality. We talk in our industry about 10x developers who produce much more and the teams that do this kind of thing. It's very variable. It's down to the individual skills of people. We don't really leverage learning and the skills across our industry and produce things more consistently. But I think that's what we should be aiming for. I think we should be aiming for something more in this territory. If software projects were normal things, there ought to be a normal distribution of software project success. As many software projects ought to finish ahead of schedule, under budget, delighting their users, as finished behind schedule, over budget and annoying their users. But I don't think that that's what we recognise as normal for our industry. I think that what we recognise as normal looks much more like that. That has quite serious implications. It colours the way that we think about establishing new projects. It colours the way in which we create teams. It colours the way that projects are funded, that they are commissioned, that they are tested, that requirements are set. All of these things are built on this assumption of failure. It means that we make all sorts of assumptions about what's normal for a software project. I think that what we're really looking at is what's normal for a software project where we've got the model wrong. A normal distribution is exactly that. It ought to be normal. If we got the model right for software development, the distribution would be normal. When we do get it right, we see some quite starkling changes in the performance of software development. We see things like 21% less time spent on unplanned work for teams that adopt these kind of more genuine approaches. 44% more time spent on developing new work rather than fixing defects. 8,000 times faster deployments. 8 times more frequent production deployments. 50% less time spent on security issues. 50% lower change failure rates. All of these kinds of numbers, they're quite surprising when you look at them. The other thing that's kind of interesting, which is slightly different, is this. This is the BBC news report of the Volkswagen engineer who was recently jailed. He was sent to jail for 40 months as a result of cheating the emissions in the Volkswagen engine management system. He wrote code that detected when a Volkswagen was under test conditions and changed the performance of the engine under those so that it would give more favourable emission results. As a result, he went to jail. That's the first time that that's happened as far as I'm aware that somebody's been held responsible for making an engineering decision. If this man had been an engineer, a qualified engineer, he would have had courses in ethics. He would have taken those when he went to university. He would have been held culpable. He could, in many countries around the world, he could have been barred from being an engineer in the future as a result of making this kind of choice. That's kind of what professions look like. I think that thinking in terms of ethics is also an important part. I'm not going to talk much more about that. I'm going to talk more about the engineering thing. But I think that's an interesting side view to think about, to add into the conversation. I particularly like this little gif animation which shows two different views of the solar system, the orbits of the planets in the solar system. I like it because it's a great analogy for talking about paradigm shifts. On the right-hand side, we've got the view of the solar system that humanity held for thousands of years. It assumed that the Earth was at the centre of the solar system and that everything in the sky revolved around the Earth. That makes perfect sense when you look at the stars, which all revolve around the Earth quite nicely, but it makes no sense at all when you look at the orbits of the planets. They make all of these screwy patterns. Sometimes the planets will go backwards in the sky because of what we're looking at. If we live in the solar system, then we can't extrapolate and Newton can't come along and come up with an inverse square law. It doesn't make any sense. An inverse square law doesn't describe what's going on here. A few centuries later, Einstein can't come along with bendy sheets of space-time and general relativity. That doesn't flow from this model either. Getting the model right is really important. A few centuries later, Copernicus came along and said, No, no, we've got it wrong. The sun's at the centre of the solar system. You've got in big trouble with that from various religious organisations. But it simplified the model. It meant that Newton could come along. It meant that Einstein could come along. It meant that we could extrapolate. It meant that even I can do the math to work out where the planets are. That stuff's important. As I said, I like this as an analogy for paradigm shift. I think that much of the software industry is essentially operates in this world. It sees software development as an enormously complicated thing, and it adds complexity on complexity to try and achieve its ends. That's a mistake. If you pair away what software development is really about, it's actually relatively simple. By adopting what I think of as an engineering discipline around some of this stuff, it improves our ability to do that. One of the things that's kind of a bit strange when you get a bunch of software to developers together and start talking about engineering is we all seem to immediately start talking about bridge building. How many times have you heard software developers say, Well, software development's not bridge building. I've heard people say that quite a lot. And it's true. It's not bridge building. But then on the whole, our view of what bridge building is isn't what we think it is either. Engineering is not all the same. It's bridge building is not the same as other forms of engineering. We can look at discipline, house building, aerospace engineering, electrical engineering, chemical engineering, mechanical engineering, civil engineering, chemical engineering. All of these disciplines are subtly different from one another. They share some common principles, but they're different. And again, engineering is not the same at different scales. If you look at these two buildings, it's quite evident. These are both, first, these are both engineered structures. If this was a, I don't know, do you have IKEA in Singapore? So if this was an IKEA shed, you can guarantee that it's engineered to be as cheap as possible and to be able to assemble easily. You can guarantee that it would be engineered to do that. This thing, the tallest building in the world, is going to be engineering on a different scale. They'll have done wind tunnel testing, finite element analysis, all sorts of things to figure out how to do that. They'll have done models of it. They'll have done computer simulations, all of that kind of stuff in this engineering. It's obvious when we look at this that the engineering involved in that thing is entirely different to the engineering that we look at this thing. However, when we talk about software, it's not quite so obvious. If I talk to somebody that doesn't understand anything about software and describe the software behind my mother's cake shop and compare that to the software behind an aeroplane control system or medical scanning device or high-frequency trading system, it's not going to be obvious that there's a big difference between those. But there is. The level of engineering that we apply is not necessarily necessary at every scale. But there are still commonalities. There are still common themes that ought to be consistent across whatever the nature of the software that we're undertaking. I've been talking kind of peripherally about engineering for a couple of years now. Occasionally, people will tweet things to me or send me messages. This is a tweet that I was sent by somebody. I've hidden their name because I really strongly disagree with what they say here. I don't want to disrespect the person that sent me the message. But what this person said was, for me, engineering means working in a certified, inflexible process that includes planning ahead a lot the antithesis of agile. I'm sorry, but I think that's nonsense. I think that's a complete misunderstanding of what engineering is about. That's confusing production for engineering. In most physical things, production is a difficult problem. If you're building aeroplanes, the design of the aeroplane is complex. That's engineering. The design of the bridge is complex. That's engineering. But also the production of the thing is complicated, too. The repetition have been able to do that. For us, production is or should be trivially simple. We push a button. It builds our software. It's done. That's production. Our problem is different. Our problem is all design. Our problem is all about discovery and creation. That's the kind of engineering I'm talking about. That's the analogy that we're talking about. That's nothing like this. This isn't describing engineering either. Let's look at some definitions and see if we can pull some words out that help us understand what we're talking about. This is from Wikipedia. It says it's about the application of empirical evidence, scientific, economic, and practical knowledge to invent, innovate, design, and maintain structures, tools, systems, components. Interesting stuff. Here's another one. This is from dictionary.com. The art or science are making practical applications of the knowledge of pure sciences to practical things. Another one, the application of scientific and mathematical principles to practical ends, efficient in economical structures again, processes and systems again. There's some common themes in here. Here's my working definition. When we're talking about engineering, here's what's going through my head. Engineering is the application of an empirical, scientific approach to finding efficient solutions to practical problems. I think that's a decent working definition that we can apply and think, wouldn't it be nice if software development was like that? One of the commonalities of engineering is the incremental approach to doing things. And that applies across the board to solving complicated problems. I am old and grumpy enough to be able to start saying things like I don't believe that humanity solves any hard problem without doing it stepwise, piece by piece. You don't build anything complicated before first building something simple. That's where you start. The shard is a fascinating building. This is a relatively new building on the London skyline. I come from England. I live about 50 miles away from this building. And the shard was really interesting in the way that it's created. Mostly, when you build a huge building like that, what you do is that you build massive foundations and then you build the building on top of it. That's not how they did this. What they did was that they built just enough foundations going down and then just a bit of the building going up. A bit more foundations and a bit more building and a bit more foundations and a bit more building and a bit more foundations and a bit more building. And as a result, they dramatically cost the cost to building this very tall building on the London skyline. They started off simply and explored, extrapolated. For me, when I start thinking about what engineering really means, particularly in the context of software development, it boils down to these five things. Roach, whatever that might be, to be iterative. We want it to employ feedback so that we can learn, adapt, reflect on what we're doing and change what we're doing. We want it to be incremental. We want it to be experimental. We want to try out ideas, evaluate ideas and learn when we're wrong and when we're right and move on the basis of that. And we want it to be empirical. We want to be using real-world discovery, not just based on theoretical models. So let's explore each of those ideas in a little bit more depth. Here's a definition from Wikipedia again. Iteration is the act of repeating a process either to generate an unbounded sequence of outcomes, not very interesting, or with the aim of approaching a desired goal, target or result. That's the bit that we're interested in. Being iterative is really important. It means that we can learn, we can react and we can adapt based on what we learn. It means that we can steer towards a goal, we can understand what's going on, we can navigate our route through the complexity of the understanding and learning and we can navigate to some destination, we can target an outcome. We can refine our approach, we can improve continually the quality of our work. And because of that repetition, it allows us to get better and better and better until we're really, really good at the things that matter. Iteration is really important. It's vital. In fact it's central to the approach really to be able to do these sorts of things. Feedback. Feedback is information about actions we turn to the source of the actions. That's a bit of a dry definition. Feedback means that we can observe the impact of our choices. We want to be able to set up our approach to doing things so that we can reflect on it again and steer again and learn again. We can gain feedback. This is my model for continuous delivery. This is a model of feedback and this is a simplified picture, a schematic of what continuous delivery is about. That the outside of these feedback loops is the crucial feedback loop of software development. We want to have an idea, we want to get that idea into the hands of our users and we want to figure out what our users make of the idea. That's pretty much what all of software development is for. At the inside we've got the really fast short feedback cycle of test driven development. We want to write a test, see it fail, write some code to make it pass, tie it all up, check it in, move on. In between we've got executable specifications and we want to get feedback from there too. We want to be incremental. As well as being iterative we want to be incremental. Incremental is about evolutionary design, continuous design, evolutive design or incremental design is directly related to any modular design application and components can be freely substituted if someone improved can ensure a better performance. That's an important part of software development. Iterative and incremental are different things, different aspects of an approach. Interesting, I'm a bit of a space nerd and the Apollo missions are a great example of modularity. This was an extremely modular system. This is the Saturn V and that bit is about getting from the Earth to Earth orbit. Sorry, just that bit. Earth to Earth orbit. This bit is from Earth orbit to Earth. This bit is from Earth to the Moon and from the Moon back to Earth again. That's the service module, that's the command module. This bit is about the bit from the Moon. The lunar module, that's the lunar descent module that took the astronauts down to the Moon. That's the lunar ascent module. It took them back up to lunar orbit. This wasn't obvious at first. The first ideas that the NASA engineers had were kind of 1950s spaceship. You had a space rocket on the ground, it flew to the Moon, it landed on the Moon and it took off from the Moon and landed all the way back. That's enormously inefficient. It also meant that they could kind of subcontract this to different organisations. This was a massive challenge for the American arms industry and the aerospace industry to be able to just build all this stuff. They were breaking new ground so they were able to farm it out to different subcontractors. Northrop, Grumman, all of these people built little bits of the system. It also meant you could compose the spacecraft in different ways depending on which phase of the mission you'd organise these things in different points. During the take-off, the lunar module was in a bay buried beneath the service module and the command module. During the journey from the Earth to the Moon, it was configured like this from the Moon to the Earth. It lost the descent module bit so you could configure the system in different ways and use it in different ways. That was remarkably useful when Apollo 13 happened and the disaster happened and we had to use this thing as a life boat. All the systems here crashed. There was no life support left in this part of the spacecraft and they flew home basically in here. This is a composable system. The other part that's interesting about incremental systems is about the units of change and the effect that that has on risk. So one of the key ideas of lean thinking is to reduce batch size. When we talk about software, what that means is minimising the number of changes. We can think about change in different ways. We could make many changes and deploy them all together. That's one level of risk. We could make many small changes and deploy them independently. That's another level of risk. Let's try and just come up with a... It's a bit of rubbish maths. Let's come up with some maths to try and describe the formula that you might think of for that. The total risk associated with releasing some software is the risk of there being an error in a change. There's a problem. The total risk is going to be depending on the number of changes. The sum of all of the risks for a change. But that's not all. There's another level of risk. There's the risk that one change might interact with another. That's going to be an exponential part of the function because as you have more changes the likelihood of those things interacting in nasty ways is more likely. You're going to have something like the risk of interaction and that's going to be a power function of some kind. In this formula for total risk, n is a significant number. The number of changes is significant. If we decide to do this to have lots of changes then n is very large. Risk is very high. If we do this instead, if we make many small changes, each one simpler, each one more composed, each one much more straightforward, then n is very small. The total risk is low. This working in an incremental way is also a way of de-risking the problem. The last thing on this is the words are a bit similar. What's the difference between iterative and incremental? I'm stealing somebody's work here. This is a picture that was in Geoff Patton's wonderful book on story mapping, which I think is the best description that I've ever seen of the difference between iterative and incremental. This is working iteratively. We're going to start off with a fully formed version at some resolution of detail and then we're going to fill in detail. Incremental is different. Incremental is about doing it in pieces, in modules. If for an engineering discipline we need both of these things, we need to be able to do sketches of the system and then be able to realise those, fill those out, but we also want to make composable systems that we can add to and bought new features on and enhance in that way too. We want to be experimental. So some more Wikipedia definitions. I want to tell you another little story based on the space program. So in 1961, John F. Kennedy, American president stood up and said to Congress, we're going to send men to the moon and bring them back by the end of the decade. And all of the people in NASA went, because they had no idea how to do that. They were nowhere near being able to do that. It was a million miles away. It was a million miles away. That was an outrageous statement at that point. At that point in history, John... Alan Shepard had been the first American into space about two weeks before Kennedy stood up in Congress. So Alan Shepard was an enormously brave man. He was strapped on top of a redstone booster at which point those rockets were blowing up all of the time. He was in a capsule. He was fired 60 miles up into space and then parachuted back down in the Mercury capsule. Enormously brave, but incredibly risky what he did. And that's all they'd done so far. This was the time when their spaceships were blowing up all of the time on the pads. They hadn't got reliable launch vehicles. So Kennedy's just kind of put this flag in the... We're going to do this. It's not my problem. You sort it out, NASA. I was talking to somebody recently who said this is probably the most expensive user story ever written. It's a very big user story. It's a very big user story. So here are the things that NASA didn't have a clue how to do at this point, which is basically all of the things that you need to be able to do. So they hadn't really got launches sorted. They were very hitting me at launching spaceships. They hadn't done multi-stage vehicles yet. They kind of got the splashdown sorted with Alan Shepard, but it was a bit hitting Miss Gross Grissom, sank his capsule on the second one. They hadn't got the flight control system really worked out. Nobody had yet done a spacewalk, Russians or Americans. Nobody had yet docked to spacecraft together. All of these things were just kind of out there. So when you're faced with a challenge like that, where on earth do you start? I think that we tend to think of NASA being very procedural, but here's the problem. Here's the problem. Here's the Earth-Moon system. This is where they're going to start from. Actually, I'm cheating. This is a kid's storybook picture of the Earth-Moon system, not the Earth-Moon system at all. This is what the Earth-Moon system looks like. This is a scale drawing. At this point in human history, no human artefact had been more than one pixel away from the Earth. First problem, how do you get from there all the way over here? You can kind of imagine the conversation in NASA the next day. What are we going to do now? I know, I've got a good idea. Let's build the spaceship, put three astronauts in it, send it to the Moon and see if they come back. Maybe not. That's maybe not the best plan. Let's build the spaceship, send it to the Moon, without the astronauts and see if it comes back on its own. No, let's not do that. I know, let's build a spaceship and just send it to the Moon. Hold on a minute. That simplifies things quite a lot. That's almost halves the problem. Bringing it back is really hard. Okay, let's send the spaceship to the Moon. What does landing on the Moon mean? Well, it doesn't have to survive the landing. That's what this was. This was the Ranger programme. These were literally spaceships as bullets fired to see if you could hit the Moon. This was the programme. The first Ranger mission was to put a Ranger spacecraft in orbit around the Earth. Blew up on the pad. If you've ever worked on a big project, the next step might amuse you. So, they've just had two failures. Yeah, but we're behind schedule. Let's go for the Moon. The third one, it got into Earth orbit. It did Earth orbit. They did the de-orbit burn and missed the Moon. The third one, it got into Earth orbit. It did Earth orbit. They did the de-orbit burn and missed the Moon. The fourth one, it got into Earth orbit. As it left, it did the de-orbit burn, headed off the Moon and all of the systems on the spaceship packed up. They managed to track it from Earth-based stations and they watched it hit the Moon. So that's progress of a kind. The fifth one, missed the Moon again. The sixth one, it got into Earth orbit. They did the de-orbit burn. The cameras packed up, but they got telemetry. It went, it hit the Moon, they got the data, but they hadn't got any pictures. The seventh one worked, the eighth one worked, the ninth one worked. So, you're NASA in the Cold War. You've essentially been given a blank check. The president said, you know, this is, we're going to beat the Russians to the Moon. You're going to do this. You can recruit anybody from the western world, any brains that can help you. What do you do? You start experimenting. That's how you do hard things. You start experimenting. You don't come up with a plan and say, that's what you're going to do all day one. You break it down into small pieces. There were millions more experiments than I've just described to get to just this stage. You start experimenting. That's how you do anything hard. So let's just think about being experimental for me. Have people seen this before? The idea is that you're supposed to figure out which is the bigger orange dot. Can I have a show of hands for people that think that this orange dot is the biggest? That's my perception. Okay. And a show of hands that people that think this orange dot is the biggest. A show of hands for people that think that they're both the same. Right, so we could carry out an experiment. They are both the same. Have people seen this one before? So this is about which of these lines is longer.  That's my perception again.  Nobody. Hands up for people that think they're both the same. It's probably more the same. Okay. You weren't paying attention. You have to do the experiment. This line is longer. I cheated. That really is longer. And so we can't tell until we do the experiment, until we measure things, until we gather data, until we figure these things out, we can't really know. We want to be empirical. Empirical, the definition of that, based on concern with or verifiable by observation or experience, rather than theory and pure logic. We often talk about maths being very close to software development. And in some ways it is. Software development kind of aligns quite nicely. I think it appeals to the same kind of brains that like maths. They tend to like software development. There's an appeal there. But it's not enough. Maths isn't enough. We've tried really hard to write provable systems. You can write provable systems. You can have languages that are provable. They're incredibly hard to write. They're incredibly difficult. So hard that you create bugs in them because it's so hard to understand what it is that you wrote. So we want to be empirical. We want to be able to try things out. We want to see what works and see what doesn't. Being empirical is important because it means that we can evidence-based. We can try stuff out and we can start separating the myths from the truths. We can start doing science. We can start being more rational about the choices that we make. So, here are my five different properties of an engineering discipline, an engineering discipline that I think software development ought to be. Actually, I'd be interested in seeing how continuous delivery my personal favourite approach to software development stacks up against this model. Well, it's incredibly iterative. It's about establishing these short cycles that allow us to adapt and learn and figure out what happens. It's grounded in the application of feedback. The deployment pipeline is a feedback mechanism. That's what it's for. Being able to automate the system, the testing, the evaluation, the deployment of the system, the monitoring of the system in production. It's all about trying to get feedback from production back into development so we can learn and understand what it is that we're building. It's incremental. It tends to push us towards more modular systems because they're more easily testable, they're more easily valuatable, and that helps us make more composable systems. It's experimental. Again, the deployment platform is the king of experimental platforms that allow us to evaluate what it is that we've done and how it is that it works. And it's empirical. It allows us to measure things and understand what really works. Continuous delivery is an engineering discipline to my mind. It's about these short feedback cycles, test-driven development, automation, hypothesis-driven, test as a falsification mechanism. We think about these things. These are scientific rational approaches to solving hard problems. And when we do this, we get the kind of results that I was talking about before. We get ridiculous improvements in the quality of our software. All those of magnitude drops in bug rates in production is common for organisations that practice this kind of discipline. The ability to create software more quickly to get it into production and understand what lands and what doesn't land, what works and what doesn't work. These are the ideas that are behind some of the most successful software companies in the world. This is how Amazon works, Google works, Facebook works, Spotify works, Netflix. These are effective companies. It's how Volvo Trucks works. It's about how NASA built the software for the Curiosity rover. Fundamentally, we're trying to do this. We're trying to make an observation. We're trying to make a theory based on what we observe. We're trying to make a prediction from the theory. And we're trying to create an experiment to validate our predictions. That's what we'd like to be able to do. What we've learnt over the years, if we want to do any sort of software development, is that we know everybody in this room knows that you don't do these as separate stages. That doesn't work very well. So these are continuous activities for all of us. All of the time we're doing design development tests, releasing all of the time. That's what works best. And what we do then is that we iterate around this approach to develop our software. This is a measure of cycle time. This is the time that it takes us from idea to working software in production. That's a useful measure to understand how efficient our process is. But what this gives us as a platform when we approach software development this way, it allows us to have our theory, make a prediction, carry out an experiment and observe the results. It allows in production. It allows us to have a theory, make a prediction, experiment inside a test environment and observe results. I think this is a genuine engineering discipline. I think this leverages our capability to create higher quality code. And when we do that, we see the results. We see that we saw that changes in orders of magnitude changes in the performance of our capabilities. That's why I think we should be taking back software engineering as an idea. I'd be happy to take any questions, thoughts, discussions. Well done. Thank you. Time to take a few questions. This isn't so much a question as a statement. You're essentially preaching to the converted here. Personally, because I see software engineering as an engineering discipline, that is why I am a member of professional engineering societies because I believe in software engineering and I believe in software engineering professionalism. And I think that it is the responsibility of people who want to call themselves software engineers to be as you mentioned in your side note, professionals and to follow a good engineering practice. And in fact, the unfortunately named extreme programming, but it's not really that extreme, is like in your illustration there a good example of engineering practice. So what is so alien to engineering as having standards like coding standards and testing things to ensure that they work? So I think it goes a little bit beyond some of those things. So first, I would agree with you that I think XP is an engineering discipline too. I'm one of the people that's calling the term continuous delivery predates the work that Jess and I did but I think that we described it to mean this kind of process of refinement and reflection. But I think of continuous delivery it's kind of like the child or the grandchild of extreme programming. Just with the scope extended a little bit. It's the same ideas. And I think that is an engineering discipline. The thing I think is really important so for me this goes quite deeply. So mostly my recent career has been writing software in kind of technically demanding regimes. I've worked in low latency finance and building exchanges and those sorts of things. These days I consult for people that are building mass spectrometers and hospital scanners and stuff like that. So it's kind of interestingly technical stuff. And I think that when you're talking about that, building software, that's kind of getting more towards the pipeline building engineering rather than the shed. And so we take these stuff fairly seriously. I think that test driven development and acceptance test driven development and high levels of automation are crucial to being I think of that as part of the discipline of engineering. I think that the things that we tend to, the things that the software industry as a whole have tended to pick up from agile are the easy things to adopt from the hard things to adopt and you've got to do the hard things, you've got to do the engineering stuff. I think that the idea of software development as a profession is a really nice one and we've kind of missed the boat. I would point out that I don't qualify to be a member of the British Computer Society because I don't have a degree. There are other roots to membership. I'd like to contribute to your rigour. Just go back to your rubbish math slide. This one?  The risk. Oh right, okay. I'm rubbish math slide. You don't like it. Being in the community, I'd like to contribute to the community. When you contribute a bit more of your rubbish maths. There we go. If you will go to your formula RC subscript N, not plus go up high product of RI subscript N. Okay. Then you get your R to M. R to N. Then for the other slide, the sub slide where you have N is smaller, it's not quite true it's N times M where N is the number of modules. I'm talking about the number of changes. N in one big change that's perfectly accurate. You go down to the next slide where you have this smaller number of modules. You have M modules and N in each M module. You do have an N times M product in there. Yeah, so I think you can still think of this as changes rather than modules. I think that's a separate direction. Okay, thank you. Thank you very much for the... You mentioned something you don't have a degree so you can't be a member of a professional organisation. One thing which is interesting between... One thing we know is that education versus work. Yep. So we know that fresh graduates computer science or engineering, engineering graduates usually they're not considered like ready to go in a real environment and that's part of the reason why something is not working without engineering approach. Yes, unlike mechanical engineering. So in craftsmanship we have this different idea of how learning is done but you didn't talk about learning part. What is your opinion about this part of craftsmanship? I think there are two bits of that that I'd like to address. So first, I think that what you're talking about is kind of the mentoring approach. Fred Brooks talked about kind of the surgeon approach where you had a surgeon and you had a consultant surgeon and he was followed around by interns who learnt from the surgeon and saw what was going on and I think that's a good model for imparting our learning, our understanding of software development. I've been involved in those kinds of programs throughout my career really as a technical leader in organisations. The other part of it I think that one of the reasons why from my point of view we teach it so badly is because we don't constrain enough we don't say what's in and what's out and I think that we should. For example I'm a hardline test driven development person I believe that when a kindergarten child learns to write their first line of code they should do that in the context of writing a test first. I think that test driven development is that fundamental. Test driven development is like double entry bookkeeping for the equivalent of double entry bookkeeping for software. You wouldn't hire an accountant who didn't do double entry bookkeeping because they would be incompetent. I don't think you should hire a software developer that doesn't do test driven development on the same basis. Software is too fragile. It's intensely fragile stuff unless you've got some level of verification which test driven development gives you you don't know whether it's doing what you intend it to do. There was an academic study this year which I can't find the reference for at the moment which analysed production failures and they estimated that 79% of production defects would not occur if people practice test driven development. It eliminates the simple things that we all get wrong all of the time and so it's important. I don't think that we should teach software development without learning how to do that. I don't think that we should be learning how to be incremental. We should be learning how to be experimental. There should be stuff on the scientific method in every computer science course. Nobody that I've talked to in the UK or America does that. I don't know what Singapore education is like but nobody in the UK or in America none of those computer science programs include science. One of the things that I think you said from the craftsmanship model that is a valuable trait to apply to software development is the idea of the apprenticeship that I'm learning. People are learning in practice from people with expertise and that's a fundamental thing from craftsmanship that should apply. It's not just about process. There's not much that I disagree with. I think that craft is important. It's just not sufficient. In addition to craft you need engineering to get more repeatability, more reliability in the process of creating software. It's still an intensively creative process. It's still going to a matter of invention every time that we write some code we're inventing. I was commenting that I disagreed that test driven development is the most important thing as you have put forward. For me I think the most important thing in the scientific method which I think underlines the entire methodology. I think the most important thing to me is the teaching of communication. The users first methodology in the agile manifesto. It's because software engineers are too focused on the engineering are too focused on the process are too focused on the math and not focused enough about asking what do the users actually want? I would disagree I mostly agree with what you said I would disagree with the idea that software developers are too focused on the engineering. They're too focused on the tech. They're too focused on the toys. Not the engineering. Not focused enough on the communication. For me software development is all about problem solving. I care much less which programming language that I use as much as I care about the way in which I divide up a problem and represent it. The programming language is secondary in terms of that kind of stuff and yet we're constantly kind of blinded by the flash bulbs of new shiny tech. Focus on building the right thing. Absolutely. Any more thoughts, contributions? Last question? No? Thank you very much indeed for your time. Thank you.