Amdahl to Zipf: The Physics of Software
Beattie, Dylan
It's easy to think software is magic - but it's not. Most of the time, it's not even sufficiently advanced. Like everything else in our world, the people you work with and the products they build are subject to the fundamental laws of nature. In this talk, Pieter Hintjens and Dylan Beattie will explore the laws of our universe - from Amdahl to Zip, from Newton's Laws of Motion to Heisenberg's Uncertainty Principle, from Conway to Murphy to Godwin to Moore. We'll discuss how they apply to your projects, even when you want to pretend they don't, and explain why if you ignore them, your work will collapse like a badly-designed bridge.
 All right, three o'clock, let's get started. Good afternoon, NDC. Before we get started, there are some things that you are not going to see in this talk, and I will tell you what they are right at the beginning, so if that's what you are here for, you can leave with no hard feelings. You will not see any code. You will not see any slides. You will not see any PowerPoint animations. And unfortunately, you will not see Peter. This talk was originally pitched as a... Peter Hinchins did a keynote at Coding Serbia last year, where he talked about the laws of physics as they are applied to software systems. And we were talking about this in a bar in Vilnius, and basically I loved this idea, and we started bouncing things backwards and forwards. It was really, really interesting. I said to him, why don't we do it at NBC Oslo as a double act? He said that sounds like a good idea for reasons those of you who know him will understand. He's not here. So, if you want to see PowerPoint, I believe they have some in the next room. I'm going to talk to you. I am going to talk to you about the laws of physics. There are all of these wonderful laws that people have discovered and refined and proposed and proved over the years. And some of these laws can apply to the software projects and the teams and the communities that we work in every day. I'm assuming most of the people here in this room were all developers of some sort or another. We worked on teams, we got stuff done, we built systems. And there are interesting observations about the way that we interact, because software is about people. And people are subject to the same physical laws that govern the universe we live in, just like everything else. And some of this is going to be fairly entertaining and high level, and some of it is actually going to be fairly specific. And we're going to do it in chronological order. Starting with Isaac Newton. Newton was a genius. Newton basically founded the principles of modern physics and mechanics. Newton was so smart that in the 16th century he came up with a set of laws which tell you why distributed software teams will fail. He just didn't know that's what he'd done until four centuries later when we looked it up and went, that's interesting. So Newton was a fascinating guy. He basically had three different careers. First he was a physicist or a natural scientist at the University of Cambridge, and he published the Principia Mathematica, or he basically laid out all these rules about how things work, how planets move, how gravity works, how all these kinds of things happen, how they behave, how to predict their influence. Then he became an alchemist for a while, and we don't talk about that very much, because he wasn't nearly as successful at turning lead into gold as he was at understanding planetary motion. And then he came to London and he ran the Royal Mint and did that for the last chapter of his life. So we're going to talk about Newton's Laws of Motion. So Newton's first law, which was published in Principia Mathematica in 1600 and something, basically says something that is at rest, something that's not moving, will not move. It will remain at rest until a force acts upon it, and something that is already moving will continue moving at a constant speed in a straight line until a force acts upon it. So there's a force that's not moving unless there is a force, a motive, an incentive for something to start happening. This is why when you wake up in the morning you think, I'm not going to move. I am at rest right now, and Newton says I should remain at rest. And then you remember that you have bills to pay, and if you don't get up and get online or go into your job or whatever, then you probably won't get paid. And so there is an economic motive, there is a force acting upon you, which will get you out of bed and get you moving. And the same thing is true of teams and companies. So, you know, organizations, startups will see an opportunity that will think, hey, we were talking in the show last night about the fact that the CEO of Uber doesn't have a driver's license. His driver's license expired, and the joke is that it's so Silicon Valley that when your driver's license expires, instead of getting a new one, you do a startup that will get people to pick you up from your door, because it's more fun and it's easier. So there are two kinds of force here. There's sort of attractive force. There's economic opportunity. There's seeing something and going, there is something here, we could go and do something, we could get rich, we could change the world, we could make this a better place. And then there is, if you like, the push force, the fear, where you're being driven to do something by, sometimes it's by threats from competition, sometimes it's legislative, sometimes it's, you need to do some work because a piece of your stack is like a ticking time bomb and you know that you're going to run out of a dress space or run out of capacity. So you have this idea of forces. Now, you ever worked in a company where they've been doing something happily for 10 years and you turn up and you try and change something and they're just like, no, no, we don't do that. This is not how we work, we do this. This is the same thing. Once they're moving in a straight line, they'll just keep trucking on. And Newton's Law is anyone who remembers studying them in high school, you always had these things in your examinations where it's like, you know, imagine a weight sliding down a smooth frictionless plane in a vacuum, which doesn't happen, you know, unless you're going ski jumping on the moon. But friction is a force and friction applies to real objects in the real world. It's why things slow down and friction applies to organizations as well. Even if you've got a team who are working and that, you know, the goal is focused, you're building a project, you have something to ship. Day by day, the kind of novelty and the initial push, you know, you will have the kickoff meeting where it's really exciting and it's inspiring and it's visionary. And a couple of weeks down the line, you're like, this isn't really quite as much fun as it used to be. And so it slows down because that organizational friction is a force. And that force will slow down the people and the teams that you're depending on to make these things happen. Newton's Second Law. This is the one you probably will remember from school. F equals MA. Force is mass times acceleration. Acceleration is how fast you can change something. You can change something by moving it very, very, very slowly, but to actually change direction. So acceleration is any change in direction. If you're moving, if you stop, that's an acceleration, negative acceleration. If you're standing still and you start moving, that's an acceleration. If you're going this way and you need to go that way, if you're running Mac, you need to switch to Windows. If you need to get everything from Pearl to Python, it's change of direction and that's an acceleration. And the force required to affect that acceleration scales with the size of the thing that you are trying to change. This is why startups can go, oh, hang on, this chat room that we've got, people are quite liking the fact they can share photographs on it. Let's turn our company into a photo sharing thing which has comments and that's how Flickr turned it from a chat service into an online photo album because they're small. They don't have a lot of mass. They don't have a lot of inertia. Startups can pivot really easily. You compare this to big organizations, Microsoft, Oracle, Sun Microsystems. These organizations are big. Start thinking about these in terms of super tankers, massive, massive, heavy structures that do not change direction easily. Now, the thing about F equals MA, you need to think about the time that it is going to take. You can steer a super tanker by very gently pushing for about six weeks and it will very slowly come about. If you want to do a handbrake turn in a super tanker, stuff is going to get broken because you are applying a massive force to affect a big acceleration on something which is massive. If you've ever, I'm sure there are people here who have been in organizations where somebody has used the fact that they are powerful to try and implement this kind of change. You get an email comes down from the CTO, from tomorrow there will be no more GitHub. We are using Team Source Safe for everything. They can do it because they are powerful so they can wield massive force. But trying to wield that force to a large organization to affect that change in a short space of time will break things. If they do this with enough authority behind them, sure, by the end of next week there will be no GitHub users left in the organization, but it's not necessarily because they've all gone and done the thing that you wanted them to do. It will be because they've left. So this is the equivalent, you know, visualize someone handbrake turning a super tanker into an iceberg. It's a very destructive mental picture, but when you are trying to affect large changes to large organizations in a very short space of time, that's effectively what you are trying to do. Newton's third law. For every action there is an equal and opposite reaction. This is the thing you push something, it pushes back. I'm standing here right now. I'm pushing down, Flora is pushing me back up. By happy coincidence they are exactly the same. I mean, that's why I can't fly, but it's also why I'm not sinking into the ground. You get this in organizations as well. You try and change something, there will be resistance. You propose something, people will push back at you. Hey, you know, I think we should stop sending out Word documents and we should do our updates on the Wiki. They'll be like, no, we don't like the Wiki. It's like, the Wiki is great. Everyone can read it. It's online. Anyone can edit it. I don't like anyone editing it. You get this reaction, it pushes back. The other interesting thing about the equal and opposite reaction is if you have one of these massive organizations, lots of inertia, lots of people, lots of money, you can use that as a springboard. Very, very small organizations, if they try and fire off something to go and explore a new opportunity or a new venture, it can actually, it can split the team because suddenly they don't have the bandwidth to cope anymore. But if you are, say, Microsoft, who are steaming along down the software industry with, you know, however many billion dollars in Windows and Office revenue behind you, and you suddenly realize that Sony and Nintendo and Sega are about to start winning the console war and you think it would be a great idea if Microsoft had a console, you can't steer the super tanker. Microsoft, the organization could not have pivoted to focus on games consoles as their primary area of business. But what they could do is leverage the mass that they had to spin off the Xbox division without worrying that that was going to disrupt what they were doing. You know, Xbox may have failed, but I don't think anyone would ever consider that spinning off a small team to go and develop a games console was an actual threat to Microsoft. You know, there's the marketing risk and there's the odd piece of brand fallout. But in terms of the core operation of that organization and the way that it works, the fact that they have that mass and that inertia allows them to spin things off against it at, you know, relatively little risk to what they're doing. So that's Newton's predictions about software teams and organizations written down in Latin in the 16th century. And, you know, here we are today exploring them and thinking about how they apply to what we're doing. There is another thing called the equivalency principle. The equivalency principle is an observation in physics that effectively says it is impossible to tell the difference between gravity and acceleration. You don't know if you're in orbit or you're falling until you hit the ground because you cannot distinguish as an observer, you cannot distinguish between acceleration that is because of gravity and acceleration that is because of a force that's being applied to it. Science fiction tropes love this. You ever read any of those books where they have the spacecraft that accelerates all the way so that there's gravity from the fact that the engines are pushing? And then when they get to the halfway point, the whole ship turns around and it does the rest of the journey in reverse and it's breaking the whole way. And so that acceleration and then breaking provides an artificial gravity for all the people who are on board. So an idea Arthur C. Clarke used a couple of times. Now the interesting thing about the equivalency principle is that it applies to observers within the frame of reference that you're talking about. There is a thing in aviation that's called a graveyard spiral. Now graveyard spiral is when you're flying in cloud, you can't see anything, your instruments are out and you think you are flying straight and level. And what you're actually doing is you are banking in a turn like this, but because the centripetal force from the turn feels just like gravity, you think you are in level flight. And because the gravity is coming from the turn, you're not conscious of the fact that you're falling. Now to somebody outside, it is completely obvious that you are not in level flight, you are doing this. Someone could see you on radar or something, they'd be like, hey, pull up, pull up, pull up, you know, you're in a deep problem situation here. The point about this is that from within our teams and within our organizations, it can be very, very difficult to tell whether we are doing the right things or not, until you hit the ground and realize that you've been falling all of this time. You know, projects where you're delivering code, you're working hard, you're shipping things, and then suddenly you realize that actually this is, you're not going to get out in time. Your version one product is targeting the wrong device. There are issues with your deployment strategy, something happens and splat, you know, you hit the ground, you face plant and things over. So the point about this, the equivalency principle is going to bite you because from inside it's impossible to tell the difference between being in a stable orbit and being in free fall. So you need external observations, you need somebody from outside who is looking in or, you know, observing what you are doing to allow you to tell the difference between these two scenarios. Which means you need to measure things, you need to set up some metrics. And the problem with measuring things is something called the uncertainty principle. So Werner Heisenberg has come over to say London from Germany, he's driving down the motorway, he's in his BMW, and because in Germany the Autobahn has no speed limit, he's, you know, got his foot down, he's going a feral clip and the police pull him over. And they say to him, you know, hello Mr. Heisenberg, do you know how fast you were going? And he says, no officer, but I know exactly where I was. And the policeman says, we just clocked you doing 120 miles an hour mate. And Heisenberg says, great, now I'm lost. Okay, so the people who were laughing know what the uncertainty principle is. Heisenberg basically observed that in subatomic physics, you cannot measure the position of a particle without affecting its velocity. So the more accurately you know the position, the less accurately you know how fast it's moving. And the more accurately you can measure how fast it's moving, the less accurately you know where it is. To measure more accurate velocity, you measure over a longer distance, which means you have more uncertainty around where the particle is during the measurement. To measure its position, the only way to do that is to bounce something off it. Imagine you've got like a soccer ball in a dark hall and you're trying to find out where it is by throwing golf balls. And sooner or later one of them is going to go ping and come back at you. But as you do that, the soccer ball is going to start rolling because someone just threw a golf ball at it. In software, we try and measure things all the time because it is very, very difficult in a lot of organizations and in a lot of programming methodologies and things to tell how good your progress is, to tell how well you are doing. Are you going to hit your deadline or not? And by trying to measure things about the way our systems work, you can actually interfere with them to the extent they stop working. A completely degenerate example of this, someone comes in and goes, look, this whole fixed salary thing is nonsense. We're going to pay you all per line of code. Software is code and we need code because we need to finish it. So from now on, at the end of every day, tell us how many lines of code you have written and we will pay you $1 for every line of code. How many people in here would be millionaires by the end of the morning? Because when they start measuring lines of code, you stop going, no, I'm not doing unit tests anymore. I'm just going to put new lines in. And then you can't, okay, I'm going to put empty statements. And you know, there's all sorts of measuring things. It's quite common in agile. One of the reasons why agile teams and scrum says you should estimate everything in points is because people used to estimate in hours. And then people would use the hours as a yardstick to measure them against. You said this ticket would take four hours. Why isn't it finished? You know, you started at one o'clock and I've checked in with you at two o'clock and three o'clock and four o'clock and five o'clock and it's still not done. And you're like, well, no, four hours was a sort of, if you add up all the tickets we do in a year and divide them by the number of tickets, you probably get some averages out, but these are not absolute accurate metrics. And there's all kinds of ways of measuring things. Anyone ever build websites and then go and run them through the W3C XHTML validator. So you get that green tick that says, you know, well done, good job. Your customers don't care if your HTML validates. The only person who cares about that is you. And there's nothing wrong with the sort of craftsmanship and professional pride. But never once have I had someone who's like, yeah, new product is ready. Customers want to buy it, but we're not shipping it because the HTML doesn't validate yet. So it doesn't matter. That's not the thing you should be measuring. Look at why you're there. What was the force that got you moving in the first place? How do you measure that, you know? If you're trying to be Uber, how many drivers, how many rides, how much revenue? If you're trying to be Spotify, how many bands, how many albums, how many streams, what is it you are trying to do? Because if you try and measure something else, you are going to end up affecting the team and the system that is trying to deliver something because they're going to start delivering the thing that's being measured because that's what they're being assessed on. You know, that's where the sense of value is coming from. So there you go. That's kind of the end of the deep theoretical physics stuff. It's going to get a little bit silly now. Murphy's Law. Murphy was, apocryphally, an engineer working in the United States Air Force in the 1960s. They were doing experiments with deceleration on rocket sleds. So they'd get a crash test dummy and they would put it in a chair on a sledge on a railway and they would put a rocket on the back of it and they'd smack it into a wall as hard as they could. And then they were like, down we didn't actually get any readings out of that. All we did is broke the dummy. So they come up with this idea of using strain gauges on all the seat belts so that when the thing crashed into the wall, they'd be able to tell afterwards how much strain each of the contact points on the harness had been subjected to. And John Stapp, I believe was his name, was the Earth Force Colonel conducting the experiment and Murphy was the guy who installed the strain meters. And the strain meters were symmetrical. They were physically symmetrical, but they only worked one way round. And he installed every single one of them backwards. And the phrase Murphy's Law was immortalized in a paper that Stapp wrote afterwards where depending which version of this you read and where the provenance comes from, is either if something can fail, it will fail, or if there's a way of getting it wrong, that bugger will do it. Murphy's Law is interesting because Murphy's Law is something that you want to keep in your head when you're thinking about user experience interaction and the way that you design and build your systems. So one of the sort of great examples of this is the old joke, when the inventor of USB dies, they're going to lower his coffin into the hole, stop, pick it up, turn it over, and lower it in again. USB is, so for starters, you get systems where you can actually destroy something. One of the interesting distinctions between the United Kingdom where I'm from and most of Europe is that you can't put our plugs, our mains plugs in upside down. With alternating current, it doesn't really matter because life neutral, neutral life, there aren't very many sort of consumer devices that are sensitive to that. But I always find it a bit interesting, you know, I have an extension cord where I put a European plug on a UK four-way brick so I can plug laptops and things in. I had to go and buy a Norwegian plug for it. And I opened the thing up and I'm like, which way around do you wire this? And it's like, actually it doesn't matter, you know. But if it did matter, then every time you plugged in a kettle or a laptop or anything in Europe you'd have a 50-50 chance of blowing it up. Because if the plug fits the wrong way around, and it shouldn't, now USB looks like it'll fit the wrong way around, but then you realize as you get in and there's actually a thing inside it that stops you inserting it backwards. Nine-volt batteries, little, you know, the PP3 batteries, the rectangular ones. You know they've got a little crown and they've got a little knobble on the top so that you can't connect them the wrong way around. It's exactly that, you know. If it matters which way around something is going to be done, make it impossible to get it wrong. Don't build a strain gauge that looks exactly the same until you crash it into a wall with a crash test dummy on it. The Apple Lightning connector, the one they use on the new iPhones, I think is a brilliant example of this because it works both ways. It's like a European plug. You know, it's a USB connector, but it doesn't matter if it's this way up or that way up so you can't get it wrong. You can't have that thing of scrabbling and going, yeah, it won't fit in having to turn over and do it the other way like you do with micro USB. The other thing where Murphy's Law is interesting is thinking about the interactions between your users and your systems because if somebody is going to... You're building an input, say, on a form and you're testing it. Somebody out there is going to do the wrong thing. Somebody is going to do it. The joke I love about this is a bad software tester walks into a bar. They order a beer, two beers, glass of wine, gin and tonic, packet of peanuts, chick, you know, it's good to go. The bar is ready. A good software tester walks into a bar. They order one beer, two beers, a glass of wine, minus one beers, a million beers, infinity beers, a lizard. Because they're testing the edge cases. Because it is all too common for us as developers. Because we have developed these mental models of the interaction models the systems were building, you have a picture in your head of what your user is like. And sometimes when you meet a real one, it can be a real shock because they are nothing at all like the person you had imagined was going to be using your system. So when you are testing, when you are developing, you know, systems and putting things together, don't always think, how can we make this right? Concentrate on the golden path by all means. If your users are smart, they are paying attention, they are doing the right thing, make that as seamless and painless and pleasant as possible. Because user experience is so fundamental to delighting users. But also think about what can go wrong. Because Murphy's law says if something can go wrong, it will eventually. There is a corollary that says it will also go wrong at the worst possible time. But, you know. Okay, so 10 laws of software development. We have Newton, 1, 2, 3. We have had the equivalency principle, we have had the uncertainty principle, we have had Murphy's law. Zipf's law. Zipf was a linguist and Zipf discovered something which is true and is freaky as hell and no one knows why it is the case. Zipf was analyzing the frequency of words in natural language, spoken language and written language. The most common word in English is the. The second most common word in English is of, which in any reasonable corpus of written English occurs about half as much. The third most common word is and. It occurs approximately one third as much. The 5,570th most common word in English is source. And it occurs almost exactly one 5,570th as often as the word the. There is this remarkable power law distribution of natural language and no one understands why this is the case. And when you start looking for it, you find that the same power law distribution starts cropping up in all kinds of places. If you look at the populations of large cities, the United States is a good example of this. The second most popular city has about half as many people as the first. The third most populace had about a third as many people. Fourth, and this distribution follows all the way down. And there is one theory that this is just, it's a product of the fact that we are human beings and we subconsciously as a, you know, society, as a group, we tailor and we optimize the things we have to worry about to keep them at a manageable scale. We want, you know, something which is infrequent. Naturally, we are wary of using it more often because it is infrequent. So it seems alien. The word there is very familiar. People use it readily because they're comfortable with it because they see it all the time. It's always there. It's omnipresent. A word like source, you need a more specialist application for. This 80-20 rule crops up all over the place. It occurs in code bases. If you look at the number of function calls and function routines and cyclomatic complexity of your code, then you'll find a similar parallel distribution. You'll have something at the top. You'll have something that's used about half as much, about a third as much. And this is very closely aligned to something called the Pareto principle, which is also known as the 80-20 rule, which also applies in all sorts of situations. Basically, 80% of your users will only ever use 20% of your features. Have you ever had the experience where you come into work on a Monday, or you sit down and work at home on a Monday, and by the end of the day, you're pretty much finished something? And then it takes you the whole rest of the week just to get the couple of bugs out and get it rendering in this one browser and work out why that unit test is failing? 20%, literally one day out of five. Monday, Tuesday, Wednesday, Thursday, Friday. And then Monday is the 20% of the time where you get 80% of the feature set done and delivered. And then it takes you the rest of the week to do all the little snagging edge cases that really aren't that important, but if you're going to ship the thing, they've got to be right. As I said, 80% of the bugs and defect reports in your software will come from 20% of the lines of code. I'm not going to go as far as saying that on Teams, 80% of the work is done by 20% of the people. But I'm sure some of you are thinking, hang on. And yeah, ZipSlau is, it's true. It holds true for all sorts of data sets and things. It's really interesting to think about when you're prioritizing and you're deciding the feature set and scale of the systems that you're going to build, but we don't know why it's the case. There's just something about things created by people that likes them to follow a power law distribution. And I would be fascinated if one day they actually find out why. So, seven laws, we're going to move on to the last three. The last three are where we start really talking about laws of software, as opposed to, you know, taking laws of physics and trying to make them fit and stuff. So the last three laws we want to talk about are Amdahl's law, Conway's law, and Moore's law. Amdahl's law is about the rate of improvement you can achieve in parallel computation by adding more resources to it. So, okay, good example. They say we're organizing a party. We have a nice big NDC after party tonight, and we need to prepare for it. And we've got, I don't know, 150 people in this room, 50 people in this room say. So we want to make a little bag with sweets and, you know, stickers and stuff for everybody, because it's not a party unless you get a little bag. And we need to go and pick up the cake. And the cake is in Sweden because we messed up the ordering. So we have a workload. We've got 50, say it takes 10 minutes to make one of these little party bags. So we've got 50 pieces of work that take 10 minutes each. So that's 500 minutes, 10 hours, give or take. And somebody needs to get a train to Sweden, which will take four hours, and pick up the cake and bring it back. Take another four hours. So if you, sir, I nominated you and said you're going to have to do all the work because when I did this is your party, you're going to have to do it. How long is it going to take you? So yeah, you've got, you know, 10 hours to make up all the party bags, and then eight hours to get to Sweden, bring the cake back. So you're looking at 18 hours. Say, take short days, long lunches, call it three days worth of work. Get someone to help you. So you say, come on, let's help out. You're going to make half of the party bags here. So you're going to make 25, you're going to make 25. So suddenly you've reduced the workload involved. You can do a day and you can do a day. You've got all the bags made, and then someone has to go and pick up the cake. So someone says, well, this is good. Why don't we get someone else to go and pick up the cake while we make party bags? So we'll get you to help out. So you go to Sweden, pick the cake up. Bang, we've gone from three days to two days to one day. You, you, you, you, you, you, you, you, you, you. Everyone here all decide they're all going to pitch in and make party bags. How long is it going to take? One day. There is no way adding more people can achieve that in less than a day because we have a piece of time-bound work that cannot be parallelized. There is no way that someone can bring the cake back while someone is on the train to Sweden to pick it up. And this, what it does is it imposes an upper limit on the number of effective cause threads, processes that will give you any improvement in how a piece of work is being done. There's a lot of work. So Moore's Law, the other one we're talking about here, Gordon Moore worked for Intel. I'm sure you're all familiar with Moore's Law. He basically had said that computers get twice as fast for the same money every 18 months. Originally his observation was, this was back in the early 1980s I think, and he observed that the number of transistors you could fit on the same piece of silicon was doubling every 18 months. And he thought this would probably be true for about another two or three years. It has proved to be true for two or three decades. You know, it was absolutely spot on. And because so much systems design an interaction and system capability scales directly with the amount of processing power, which is the number of transistors you can fit on a silicon wafer, basically computers get twice as fast every 18 months for the same price. So on the one hand we have systems becoming more and more powerful in terms of the amount of parallelism they can do. On the other hand we have Amdahl's Law which imposes limits on how much computation you can actually, how much of an improvement you can get by adding more process to it. Now what's interesting with Amdahl's Law is think about it in terms of people. So go back to our example there. So there we've got a project that we cannot parallelize. There is no way we can organize a party, you know, it's hop us three now, the conference finishes it, hop us six. There's no way we can have our party ready to go in three hours, no matter how many people we hire to help us organize it. If you are working on a software team and you have activities which cannot be parallelized and are time bound, they impose an upper limit on how much faster you can go by adding more people to it. The classic example of this is meetings. If you have eight hours worth of meetings that are necessary because that's how your project works, there is no way you can hire enough people to do that project in less than eight hours. So it imposes an upper limit on take the total amount of time you've got 20 days of work to do except two days of the meetings. You can get 10 people on that team, but the 11th person will have nothing to do because the meetings are happening and everyone else is already busy. And that's it. All of the work is being taken care of. All your tickets are in flight. Everything is already happening. So these patterns of locking components, if you think about distributed system design, so imagine for one second that we had an online commerce website. The customer is going to connect to our website. They are going to place an order. We're going to talk to the inventory system, determine that we've got that particular type of, I don't know, NDC party cake, ordering a cake online because we're not going to go to Sweden. So we go on, we order the cake, check with the inventory. Do we have the cake? Yes. Respond. Check with the account system. Is this customer validated? Yes. Okay. Do you have a message to the warehouse system? Please ship this cake to this address. Yes. And then send a response back. And those systems may take, you know, three, four, five seconds to recover. But what we're going to do, whenever anyone hits our website, we are going to set up a massive distributed transaction and take an atomic lock on every single component in the entire system until all of them, they are not allowed to deal with any other requests or process any other work. So whilst we're ordering the cake, the website is effectively down for everyone else in the world. The inventory warehouse system is down for everyone else in the world. The stock control system is down. The delivery system is down. We look at it like that. It seems absolutely crazy, doesn't it? No one would ever build software like that. But you'll call half a dozen people into a room and sit them down to have a meeting and say, none of you can do anything else for the next two hours. We are getting very, very good at modeling distributed systems in terms of autonomous actors that have their own workload, they have their own inputs, they have their own outputs, and they can deal with the work that comes to them as effectively as possible, and these systems are easy to scale up. And this brings us on to the tenth of the laws we're talking about today, which is Conway's law. Mel Conway observed in 1964 that organizations that create systems will tend to create systems that reflect the communication structures of the organizations that build them. This is something that I've done a lot of thinking, a lot of research, and a lot of speaking about. Peter Hinchin summarized this as, if you have shit people, you'll have shit code, which is a fairly pithy kind of synopsis of how it works. What it means is if you've got two teams who, for whatever reason, communicate amongst themselves better than they communicate with the other team, you're going to end with two very tightly coupled components with some kind of interface layer between them that doesn't work quite so well. If you've got three or four or five teams, you're going to end up with three or four or five different components. If you've got teams that talk to each other very readily, then the interface between those two teams is going to be good. It's going to be fit for purpose, because those people will communicate. If you've got two teams who are very bad at maintaining the boundary, you are going to get tight coupling, because two components that were supposed to be separate end up being bound together. So we have these three laws. We have Moore's law, which says that systems are getting cheaper, computation is getting cheaper, everything is getting more expensive. When I first started doing software development, I probably spent about an hour a day waiting for my PC to do things. Now I probably spend about an hour a day waiting for my PC to do things, because we're not using all of this amazing computing power to do the same things quicker. We're using it to do more things. The fact that the amount of time you spend interacting with the system remain constant must mean that the complexity of the systems we are building is doubling. There is a lovely quote, the greatest achievement of the software engineering industry is to completely neutralize the astonishing advances made by the hardware engineering industry. So the systems are getting twice as powerful, but they're not getting twice as fast at actually doing real stuff, which means that the work they're doing is getting twice as complicated, which means we are building more and more and more complicated systems, and the complexity of those systems is doubling every few years. Conway's law says that the systems will reflect the communication structures of the organizations that created them, and Amdahl's law says that you have this upper limit on how effective your team sizes can be if you have things like meetings and work that cannot be scaled and broken down. So effectively, the message we can take, the way that we can synthesize all of these laws into recommendations and things we can think about is how we approach the task of building software differently. We've got to get better at communicating asynchronously. We've got to get better at interacting with teams and organizations. The open source model kind of got this right almost from the word go. How many people have went to a meeting for an open source project they work on? Let alone a meeting at 9 o'clock in the morning where coffee and donuts are served, you know? They got this distributed asynchronous, people do work when they're ready, they retain information and statistics and people can work on it at their own time. That model is going to become more and more widespread because in order to continue keeping pace with the development of the systems we're building, we need bigger teams. And there is a limit on how big teams get if you are doing things like having meetings. So get rid of all the meetings, make a massive distributed team that's basically everybody in the world and love the fact that everything you do is going to be running twice as fast in two years' time, because you're going to be doing twice as much with it. And I think we're going to stop it there. Thank you. APPLAUSE Are there any questions? I love it when there's no questions. It means you have all achieved complete enlightenment. So yes, thank you all very much for coming. Enjoy the last bit of the conference. Staying around over the weekend, come to Pubcon on Saturday. It's going to be awesome. Thank you very much for coming.
 All right, three o'clock, let's get started.  Good afternoon, NDC.  Before we get started, there are some things that you are not going to see in this talk,  and I will tell you what they are right at the beginning, so if that's what you are here for,  you can leave with no hard feelings.  You will not see any code.  You will not see any slides.  You will not see any PowerPoint animations.  And unfortunately, you will not see Peter.  This talk was originally pitched as a...  Peter Hinchins did a keynote at Coding Serbia last year,  where he talked about the laws of physics as they are applied to software systems.  And we were talking about this in a bar in Vilnius,  and basically I loved this idea, and we started bouncing things backwards and forwards.  It was really, really interesting.  I said to him, why don't we do it at NBC Oslo as a double act?  He said that sounds like a good idea for reasons those of you who know him will understand.  He's not here.  So, if you want to see PowerPoint, I believe they have some in the next room.  I'm going to talk to you.  I am going to talk to you about the laws of physics.  There are all of these wonderful laws that people have discovered and refined and proposed and proved over the years.  And some of these laws can apply to the software projects and the teams and the communities that we work in every day.  I'm assuming most of the people here in this room were all developers of some sort or another.  We worked on teams, we got stuff done, we built systems.  And there are interesting observations about the way that we interact, because software is about people.  And people are subject to the same physical laws that govern the universe we live in, just like everything else.  And some of this is going to be fairly entertaining and high level, and some of it is actually going to be fairly specific.  And we're going to do it in chronological order.  Starting with Isaac Newton.  Newton was a genius. Newton basically founded the principles of modern physics and mechanics.  Newton was so smart that in the 16th century he came up with a set of laws which tell you why distributed software teams will fail.  He just didn't know that's what he'd done until four centuries later when we looked it up and went, that's interesting.  So Newton was a fascinating guy. He basically had three different careers.  First he was a physicist or a natural scientist at the University of Cambridge, and he published the Principia Mathematica,  or he basically laid out all these rules about how things work, how planets move, how gravity works, how all these kinds of things happen, how they behave, how to predict their influence.  Then he became an alchemist for a while, and we don't talk about that very much, because he wasn't nearly as successful at turning lead into gold as he was at understanding planetary motion.  And then he came to London and he ran the Royal Mint and did that for the last chapter of his life.  So we're going to talk about Newton's Laws of Motion.  So Newton's first law, which was published in Principia Mathematica in 1600 and something, basically says something that is at rest, something that's not moving, will not move.  It will remain at rest until a force acts upon it, and something that is already moving will continue moving at a constant speed in a straight line until a force acts upon it.  So there's a force that's not moving unless there is a force, a motive, an incentive for something to start happening.  This is why when you wake up in the morning you think, I'm not going to move.  I am at rest right now, and Newton says I should remain at rest.  And then you remember that you have bills to pay, and if you don't get up and get online or go into your job or whatever, then you probably won't get paid.  And so there is an economic motive, there is a force acting upon you, which will get you out of bed and get you moving.  And the same thing is true of teams and companies.  So, you know, organizations, startups will see an opportunity that will think, hey, we were talking in the show last night about the fact that the CEO of Uber doesn't have a driver's license.  His driver's license expired, and the joke is that it's so Silicon Valley that when your driver's license expires, instead of getting a new one, you do a startup that will get people to pick you up from your door, because it's more fun and it's easier.  So there are two kinds of force here. There's sort of attractive force. There's economic opportunity.  There's seeing something and going, there is something here, we could go and do something, we could get rich, we could change the world, we could make this a better place.  And then there is, if you like, the push force, the fear, where you're being driven to do something by, sometimes it's by threats from competition, sometimes it's legislative, sometimes it's, you need to do some work because a piece of your stack is like a ticking time bomb and you know that you're going to run out of a dress space or run out of capacity.  So you have this idea of forces.  Now, you ever worked in a company where they've been doing something happily for 10 years and you turn up and you try and change something and they're just like, no, no, we don't do that.  This is not how we work, we do this. This is the same thing. Once they're moving in a straight line, they'll just keep trucking on.  And Newton's Law is anyone who remembers studying them in high school, you always had these things in your examinations where it's like, you know, imagine a weight sliding down a smooth frictionless plane in a vacuum, which doesn't happen, you know, unless you're going ski jumping on the moon.  But friction is a force and friction applies to real objects in the real world. It's why things slow down and friction applies to organizations as well.  Even if you've got a team who are working and that, you know, the goal is focused, you're building a project, you have something to ship.  Day by day, the kind of novelty and the initial push, you know, you will have the kickoff meeting where it's really exciting and it's inspiring and it's visionary.  And a couple of weeks down the line, you're like, this isn't really quite as much fun as it used to be. And so it slows down because that organizational friction is a force.  And that force will slow down the people and the teams that you're depending on to make these things happen. Newton's Second Law.  This is the one you probably will remember from school. F equals MA.  Force is mass times acceleration. Acceleration is how fast you can change something. You can change something by moving it very, very, very slowly, but to actually change direction.  So acceleration is any change in direction. If you're moving, if you stop, that's an acceleration, negative acceleration.  If you're standing still and you start moving, that's an acceleration. If you're going this way and you need to go that way, if you're running Mac, you need to switch to Windows.  If you need to get everything from Pearl to Python, it's change of direction and that's an acceleration.  And the force required to affect that acceleration scales with the size of the thing that you are trying to change.  This is why startups can go, oh, hang on, this chat room that we've got, people are quite liking the fact they can share photographs on it.  Let's turn our company into a photo sharing thing which has comments and that's how Flickr turned it from a chat service into an online photo album because they're small.  They don't have a lot of mass. They don't have a lot of inertia. Startups can pivot really easily.  You compare this to big organizations, Microsoft, Oracle, Sun Microsystems. These organizations are big.  Start thinking about these in terms of super tankers, massive, massive, heavy structures that do not change direction easily.  Now, the thing about F equals MA, you need to think about the time that it is going to take.  You can steer a super tanker by very gently pushing for about six weeks and it will very slowly come about.  If you want to do a handbrake turn in a super tanker, stuff is going to get broken because you are applying a massive force to affect a big acceleration on something which is massive.  If you've ever, I'm sure there are people here who have been in organizations where somebody has used the fact that they are powerful to try and implement this kind of change.  You get an email comes down from the CTO, from tomorrow there will be no more GitHub. We are using Team Source Safe for everything.  They can do it because they are powerful so they can wield massive force. But trying to wield that force to a large organization to affect that change in a short space of time will break things.  If they do this with enough authority behind them, sure, by the end of next week there will be no GitHub users left in the organization, but it's not necessarily because they've all gone and done the thing that you wanted them to do.  It will be because they've left. So this is the equivalent, you know, visualize someone handbrake turning a super tanker into an iceberg.  It's a very destructive mental picture, but when you are trying to affect large changes to large organizations in a very short space of time, that's effectively what you are trying to do.  Newton's third law. For every action there is an equal and opposite reaction. This is the thing you push something, it pushes back.  I'm standing here right now. I'm pushing down, Flora is pushing me back up. By happy coincidence they are exactly the same.  I mean, that's why I can't fly, but it's also why I'm not sinking into the ground. You get this in organizations as well. You try and change something, there will be resistance.  You propose something, people will push back at you. Hey, you know, I think we should stop sending out Word documents and we should do our updates on the Wiki.  They'll be like, no, we don't like the Wiki. It's like, the Wiki is great. Everyone can read it. It's online. Anyone can edit it. I don't like anyone editing it. You get this reaction, it pushes back.  The other interesting thing about the equal and opposite reaction is if you have one of these massive organizations, lots of inertia, lots of people, lots of money, you can use that as a springboard.  Very, very small organizations, if they try and fire off something to go and explore a new opportunity or a new venture, it can actually, it can split the team because suddenly they don't have the bandwidth to cope anymore.  But if you are, say, Microsoft, who are steaming along down the software industry with, you know, however many billion dollars in Windows and Office revenue behind you,  and you suddenly realize that Sony and Nintendo and Sega are about to start winning the console war and you think it would be a great idea if Microsoft had a console, you can't steer the super tanker.  Microsoft, the organization could not have pivoted to focus on games consoles as their primary area of business.  But what they could do is leverage the mass that they had to spin off the Xbox division without worrying that that was going to disrupt what they were doing.  You know, Xbox may have failed, but I don't think anyone would ever consider that spinning off a small team to go and develop a games console was an actual threat to Microsoft.  You know, there's the marketing risk and there's the odd piece of brand fallout.  But in terms of the core operation of that organization and the way that it works, the fact that they have that mass and that inertia allows them to spin things off against it at, you know, relatively little risk to what they're doing.  So that's Newton's predictions about software teams and organizations written down in Latin in the 16th century.  And, you know, here we are today exploring them and thinking about how they apply to what we're doing.  There is another thing called the equivalency principle.  The equivalency principle is an observation in physics that effectively says it is impossible to tell the difference between gravity and acceleration.  You don't know if you're in orbit or you're falling until you hit the ground because you cannot distinguish as an observer, you cannot distinguish between acceleration that is because of gravity and acceleration that is because of a force that's being applied to it.  Science fiction tropes love this. You ever read any of those books where they have the spacecraft that accelerates all the way so that there's gravity from the fact that the engines are pushing?  And then when they get to the halfway point, the whole ship turns around and it does the rest of the journey in reverse and it's breaking the whole way.  And so that acceleration and then breaking provides an artificial gravity for all the people who are on board.  So an idea Arthur C. Clarke used a couple of times.  Now the interesting thing about the equivalency principle is that it applies to observers within the frame of reference that you're talking about.  There is a thing in aviation that's called a graveyard spiral.  Now graveyard spiral is when you're flying in cloud, you can't see anything, your instruments are out and you think you are flying straight and level.  And what you're actually doing is you are banking in a turn like this, but because the centripetal force from the turn feels just like gravity, you think you are in level flight.  And because the gravity is coming from the turn, you're not conscious of the fact that you're falling.  Now to somebody outside, it is completely obvious that you are not in level flight, you are doing this.  Someone could see you on radar or something, they'd be like, hey, pull up, pull up, pull up, you know, you're in a deep problem situation here.  The point about this is that from within our teams and within our organizations, it can be very, very difficult to tell whether we are doing the right things or not, until you hit the ground and realize that you've been falling all of this time.  You know, projects where you're delivering code, you're working hard, you're shipping things, and then suddenly you realize that actually this is, you're not going to get out in time.  Your version one product is targeting the wrong device.  There are issues with your deployment strategy, something happens and splat, you know, you hit the ground, you face plant and things over.  So the point about this, the equivalency principle is going to bite you because from inside it's impossible to tell the difference between being in a stable orbit and being in free fall.  So you need external observations, you need somebody from outside who is looking in or, you know, observing what you are doing to allow you to tell the difference between these two scenarios.  Which means you need to measure things, you need to set up some metrics.  And the problem with measuring things is something called the uncertainty principle.  So Werner Heisenberg has come over to say London from Germany, he's driving down the motorway, he's in his BMW, and because in Germany the Autobahn has no speed limit, he's, you know, got his foot down, he's going a feral clip and the police pull him over.  And they say to him, you know, hello Mr. Heisenberg, do you know how fast you were going?  And he says, no officer, but I know exactly where I was.  And the policeman says, we just clocked you doing 120 miles an hour mate.  And Heisenberg says, great, now I'm lost.  Okay, so the people who were laughing know what the uncertainty principle is.  Heisenberg basically observed that in subatomic physics, you cannot measure the position of a particle without affecting its velocity.  So the more accurately you know the position, the less accurately you know how fast it's moving.  And the more accurately you can measure how fast it's moving, the less accurately you know where it is.  To measure more accurate velocity, you measure over a longer distance, which means you have more uncertainty around where the particle is during the measurement.  To measure its position, the only way to do that is to bounce something off it.  Imagine you've got like a soccer ball in a dark hall and you're trying to find out where it is by throwing golf balls.  And sooner or later one of them is going to go ping and come back at you.  But as you do that, the soccer ball is going to start rolling because someone just threw a golf ball at it.  In software, we try and measure things all the time because it is very, very difficult in a lot of organizations  and in a lot of programming methodologies and things to tell how good your progress is, to tell how well you are doing.  Are you going to hit your deadline or not?  And by trying to measure things about the way our systems work, you can actually interfere with them to the extent they stop working.  A completely degenerate example of this, someone comes in and goes, look, this whole fixed salary thing is nonsense.  We're going to pay you all per line of code.  Software is code and we need code because we need to finish it.  So from now on, at the end of every day, tell us how many lines of code you have written and we will pay you $1 for every line of code.  How many people in here would be millionaires by the end of the morning?  Because when they start measuring lines of code, you stop going, no, I'm not doing unit tests anymore.  I'm just going to put new lines in.  And then you can't, okay, I'm going to put empty statements.  And you know, there's all sorts of measuring things. It's quite common in agile.  One of the reasons why agile teams and scrum says you should estimate everything in points is because people used to estimate in hours.  And then people would use the hours as a yardstick to measure them against.  You said this ticket would take four hours. Why isn't it finished?  You know, you started at one o'clock and I've checked in with you at two o'clock and three o'clock and four o'clock and five o'clock and it's still not done.  And you're like, well, no, four hours was a sort of, if you add up all the tickets we do in a year and divide them by the number of tickets,  you probably get some averages out, but these are not absolute accurate metrics.  And there's all kinds of ways of measuring things.  Anyone ever build websites and then go and run them through the W3C XHTML validator.  So you get that green tick that says, you know, well done, good job.  Your customers don't care if your HTML validates.  The only person who cares about that is you.  And there's nothing wrong with the sort of craftsmanship and professional pride.  But never once have I had someone who's like, yeah, new product is ready.  Customers want to buy it, but we're not shipping it because the HTML doesn't validate yet.  So it doesn't matter.  That's not the thing you should be measuring.  Look at why you're there.  What was the force that got you moving in the first place?  How do you measure that, you know?  If you're trying to be Uber, how many drivers, how many rides, how much revenue?  If you're trying to be Spotify, how many bands, how many albums, how many streams,  what is it you are trying to do?  Because if you try and measure something else,  you are going to end up affecting the team and the system that is trying to deliver something  because they're going to start delivering the thing that's being measured  because that's what they're being assessed on.  You know, that's where the sense of value is coming from.  So there you go.  That's kind of the end of the deep theoretical physics stuff.  It's going to get a little bit silly now.  Murphy's Law.  Murphy was, apocryphally,  an engineer working in the United States Air Force in the 1960s.  They were doing experiments with deceleration on rocket sleds.  So they'd get a crash test dummy and they would put it in a chair on a sledge on a railway  and they would put a rocket on the back of it and they'd smack it into a wall as hard as they could.  And then they were like,  down we didn't actually get any readings out of that.  All we did is broke the dummy.  So they come up with this idea of using strain gauges on all the seat belts  so that when the thing crashed into the wall,  they'd be able to tell afterwards how much strain each of the contact points on the harness had been subjected to.  And John Stapp, I believe was his name,  was the Earth Force Colonel conducting the experiment  and Murphy was the guy who installed the strain meters.  And the strain meters were symmetrical.  They were physically symmetrical, but they only worked one way round.  And he installed every single one of them backwards.  And the phrase Murphy's Law was immortalized in a paper that Stapp wrote afterwards  where depending which version of this you read and where the provenance comes from,  is either if something can fail, it will fail,  or if there's a way of getting it wrong, that bugger will do it.  Murphy's Law is interesting because Murphy's Law is something that you want to keep in your head  when you're thinking about user experience interaction  and the way that you design and build your systems.  So one of the sort of great examples of this is the old joke,  when the inventor of USB dies, they're going to lower his coffin into the hole,  stop, pick it up, turn it over, and lower it in again.  USB is, so for starters, you get systems where you can actually destroy something.  One of the interesting distinctions between the United Kingdom where I'm from and most of Europe  is that you can't put our plugs, our mains plugs in upside down.  With alternating current, it doesn't really matter because life neutral, neutral life,  there aren't very many sort of consumer devices that are sensitive to that.  But I always find it a bit interesting, you know, I have an extension cord where I put a European plug  on a UK four-way brick so I can plug laptops and things in.  I had to go and buy a Norwegian plug for it.  And I opened the thing up and I'm like, which way around do you wire this?  And it's like, actually it doesn't matter, you know.  But if it did matter, then every time you plugged in a kettle or a laptop or anything in Europe  you'd have a 50-50 chance of blowing it up.  Because if the plug fits the wrong way around, and it shouldn't,  now USB looks like it'll fit the wrong way around, but then you realize as you get in  and there's actually a thing inside it that stops you inserting it backwards.  Nine-volt batteries, little, you know, the PP3 batteries, the rectangular ones.  You know they've got a little crown and they've got a little knobble on the top  so that you can't connect them the wrong way around.  It's exactly that, you know.  If it matters which way around something is going to be done,  make it impossible to get it wrong.  Don't build a strain gauge that looks exactly the same until you crash it into a wall  with a crash test dummy on it.  The Apple Lightning connector, the one they use on the new iPhones,  I think is a brilliant example of this because it works both ways.  It's like a European plug.  You know, it's a USB connector, but it doesn't matter if it's this way up or that way up  so you can't get it wrong.  You can't have that thing of scrabbling and going, yeah, it won't fit in having to turn over and do it the other way  like you do with micro USB.  The other thing where Murphy's Law is interesting is thinking about the interactions  between your users and your systems  because if somebody is going to...  You're building an input, say, on a form and you're testing it.  Somebody out there is going to do the wrong thing.  Somebody is going to do it.  The joke I love about this is a bad software tester walks into a bar.  They order a beer, two beers, glass of wine, gin and tonic, packet of peanuts, chick, you know, it's good to go.  The bar is ready.  A good software tester walks into a bar.  They order one beer, two beers, a glass of wine, minus one beers, a million beers, infinity beers, a lizard.  Because they're testing the edge cases.  Because it is all too common for us as developers.  Because we have developed these mental models of the interaction models the systems were building,  you have a picture in your head of what your user is like.  And sometimes when you meet a real one, it can be a real shock because they are nothing at all like the person you had imagined was going to be using your system.  So when you are testing, when you are developing, you know, systems and putting things together,  don't always think, how can we make this right?  Concentrate on the golden path by all means.  If your users are smart, they are paying attention, they are doing the right thing, make that as seamless and painless and pleasant as possible.  Because user experience is so fundamental to delighting users.  But also think about what can go wrong.  Because Murphy's law says if something can go wrong, it will eventually.  There is a corollary that says it will also go wrong at the worst possible time.  But, you know.  Okay, so 10 laws of software development. We have Newton, 1, 2, 3.  We have had the equivalency principle, we have had the uncertainty principle, we have had Murphy's law.  Zipf's law.  Zipf was a linguist and Zipf discovered something which is true and is freaky as hell and no one knows why it is the case.  Zipf was analyzing the frequency of words in natural language, spoken language and written language.  The most common word in English is the.  The second most common word in English is of, which in any reasonable corpus of written English occurs about half as much.  The third most common word is and.  It occurs approximately one third as much.  The 5,570th most common word in English is source.  And it occurs almost exactly one 5,570th as often as the word the.  There is this remarkable power law distribution of natural language and no one understands why this is the case.  And when you start looking for it, you find that the same power law distribution starts cropping up in all kinds of places.  If you look at the populations of large cities, the United States is a good example of this.  The second most popular city has about half as many people as the first.  The third most populace had about a third as many people.  Fourth, and this distribution follows all the way down.  And there is one theory that this is just, it's a product of the fact that we are human beings and we subconsciously as a, you know, society, as a group,  we tailor and we optimize the things we have to worry about to keep them at a manageable scale.  We want, you know, something which is infrequent.  Naturally, we are wary of using it more often because it is infrequent.  So it seems alien.  The word there is very familiar.  People use it readily because they're comfortable with it because they see it all the time.  It's always there.  It's omnipresent.  A word like source, you need a more specialist application for.  This 80-20 rule crops up all over the place.  It occurs in code bases.  If you look at the number of function calls and function routines and cyclomatic complexity of your code, then you'll find a similar parallel distribution.  You'll have something at the top.  You'll have something that's used about half as much, about a third as much.  And this is very closely aligned to something called the Pareto principle, which is also known as the 80-20 rule, which also applies in all sorts of situations.  Basically, 80% of your users will only ever use 20% of your features.  Have you ever had the experience where you come into work on a Monday, or you sit down and work at home on a Monday,  and by the end of the day, you're pretty much finished something?  And then it takes you the whole rest of the week just to get the couple of bugs out and get it rendering in this one browser and work out why that unit test is failing?  20%, literally one day out of five.  Monday, Tuesday, Wednesday, Thursday, Friday.  And then Monday is the 20% of the time where you get 80% of the feature set done and delivered.  And then it takes you the rest of the week to do all the little snagging edge cases that really aren't that important,  but if you're going to ship the thing, they've got to be right.  As I said, 80% of the bugs and defect reports in your software will come from 20% of the lines of code.  I'm not going to go as far as saying that on Teams, 80% of the work is done by 20% of the people.  But I'm sure some of you are thinking, hang on.  And yeah, ZipSlau is, it's true.  It holds true for all sorts of data sets and things.  It's really interesting to think about when you're prioritizing and you're deciding the feature set and scale of the systems that you're going to build,  but we don't know why it's the case.  There's just something about things created by people that likes them to follow a power law distribution.  And I would be fascinated if one day they actually find out why.  So, seven laws, we're going to move on to the last three.  The last three are where we start really talking about laws of software,  as opposed to, you know, taking laws of physics and trying to make them fit and stuff.  So the last three laws we want to talk about are Amdahl's law, Conway's law, and Moore's law.  Amdahl's law is about the rate of improvement you can achieve in parallel computation by adding more resources to it.  So, okay, good example.  They say we're organizing a party.  We have a nice big NDC after party tonight, and we need to prepare for it.  And we've got, I don't know, 150 people in this room, 50 people in this room say.  So we want to make a little bag with sweets and, you know, stickers and stuff for everybody, because it's not a party unless you get a little bag.  And we need to go and pick up the cake.  And the cake is in Sweden because we messed up the ordering.  So we have a workload.  We've got 50, say it takes 10 minutes to make one of these little party bags.  So we've got 50 pieces of work that take 10 minutes each.  So that's 500 minutes, 10 hours, give or take.  And somebody needs to get a train to Sweden, which will take four hours, and pick up the cake and bring it back.  Take another four hours.  So if you, sir, I nominated you and said you're going to have to do all the work because when I did this is your party, you're going to have to do it.  How long is it going to take you?  So yeah, you've got, you know, 10 hours to make up all the party bags, and then eight hours to get to Sweden, bring the cake back.  So you're looking at 18 hours.  Say, take short days, long lunches, call it three days worth of work.  Get someone to help you.  So you say, come on, let's help out.  You're going to make half of the party bags here.  So you're going to make 25, you're going to make 25.  So suddenly you've reduced the workload involved.  You can do a day and you can do a day.  You've got all the bags made, and then someone has to go and pick up the cake.  So someone says, well, this is good.  Why don't we get someone else to go and pick up the cake while we make party bags?  So we'll get you to help out.  So you go to Sweden, pick the cake up.  Bang, we've gone from three days to two days to one day.  You, you, you, you, you, you, you, you, you, you.  Everyone here all decide they're all going to pitch in and make party bags.  How long is it going to take?  One day.  There is no way adding more people can achieve that in less than a day  because we have a piece of time-bound work that cannot be parallelized.  There is no way that someone can bring the cake back while someone is on the train to Sweden to pick it up.  And this, what it does is it imposes an upper limit on the number of effective cause threads, processes  that will give you any improvement in how a piece of work is being done.  There's a lot of work.  So Moore's Law, the other one we're talking about here, Gordon Moore worked for Intel.  I'm sure you're all familiar with Moore's Law.  He basically had said that computers get twice as fast for the same money every 18 months.  Originally his observation was, this was back in the early 1980s I think,  and he observed that the number of transistors you could fit on the same piece of silicon was doubling every 18 months.  And he thought this would probably be true for about another two or three years.  It has proved to be true for two or three decades.  You know, it was absolutely spot on.  And because so much systems design an interaction and system capability scales directly with the amount of processing power,  which is the number of transistors you can fit on a silicon wafer,  basically computers get twice as fast every 18 months for the same price.  So on the one hand we have systems becoming more and more powerful in terms of the amount of parallelism they can do.  On the other hand we have Amdahl's Law which imposes limits on how much computation you can actually,  how much of an improvement you can get by adding more process to it.  Now what's interesting with Amdahl's Law is think about it in terms of people.  So go back to our example there.  So there we've got a project that we cannot parallelize.  There is no way we can organize a party, you know, it's hop us three now, the conference finishes it, hop us six.  There's no way we can have our party ready to go in three hours, no matter how many people we hire to help us organize it.  If you are working on a software team and you have activities which cannot be parallelized and are time bound,  they impose an upper limit on how much faster you can go by adding more people to it.  The classic example of this is meetings.  If you have eight hours worth of meetings that are necessary because that's how your project works,  there is no way you can hire enough people to do that project in less than eight hours.  So it imposes an upper limit on take the total amount of time you've got 20 days of work to do except two days of the meetings.  You can get 10 people on that team, but the 11th person will have nothing to do because the meetings are happening and everyone else is already busy.  And that's it. All of the work is being taken care of. All your tickets are in flight. Everything is already happening.  So these patterns of locking components, if you think about distributed system design,  so imagine for one second that we had an online commerce website.  The customer is going to connect to our website. They are going to place an order.  We're going to talk to the inventory system, determine that we've got that particular type of, I don't know, NDC party cake,  ordering a cake online because we're not going to go to Sweden.  So we go on, we order the cake, check with the inventory. Do we have the cake? Yes. Respond.  Check with the account system. Is this customer validated? Yes. Okay.  Do you have a message to the warehouse system? Please ship this cake to this address. Yes.  And then send a response back. And those systems may take, you know, three, four, five seconds to recover.  But what we're going to do, whenever anyone hits our website, we are going to set up a massive distributed transaction  and take an atomic lock on every single component in the entire system until all of them, they are not allowed to deal with any other requests or process any other work.  So whilst we're ordering the cake, the website is effectively down for everyone else in the world.  The inventory warehouse system is down for everyone else in the world. The stock control system is down.  The delivery system is down. We look at it like that. It seems absolutely crazy, doesn't it?  No one would ever build software like that. But you'll call half a dozen people into a room and sit them down to have a meeting  and say, none of you can do anything else for the next two hours.  We are getting very, very good at modeling distributed systems in terms of autonomous actors that have their own workload,  they have their own inputs, they have their own outputs, and they can deal with the work that comes to them as effectively as possible,  and these systems are easy to scale up. And this brings us on to the tenth of the laws we're talking about today, which is Conway's law.  Mel Conway observed in 1964 that organizations that create systems will tend to create systems that reflect the communication structures of the organizations that build them.  This is something that I've done a lot of thinking, a lot of research, and a lot of speaking about.  Peter Hinchin summarized this as, if you have shit people, you'll have shit code, which is a fairly pithy kind of synopsis of how it works.  What it means is if you've got two teams who, for whatever reason, communicate amongst themselves better than they communicate with the other team,  you're going to end with two very tightly coupled components with some kind of interface layer between them that doesn't work quite so well.  If you've got three or four or five teams, you're going to end up with three or four or five different components.  If you've got teams that talk to each other very readily, then the interface between those two teams is going to be good.  It's going to be fit for purpose, because those people will communicate.  If you've got two teams who are very bad at maintaining the boundary, you are going to get tight coupling,  because two components that were supposed to be separate end up being bound together.  So we have these three laws. We have Moore's law, which says that systems are getting cheaper, computation is getting cheaper,  everything is getting more expensive.  When I first started doing software development, I probably spent about an hour a day waiting for my PC to do things.  Now I probably spend about an hour a day waiting for my PC to do things,  because we're not using all of this amazing computing power to do the same things quicker.  We're using it to do more things.  The fact that the amount of time you spend interacting with the system remain constant  must mean that the complexity of the systems we are building is doubling.  There is a lovely quote,  the greatest achievement of the software engineering industry is to completely neutralize the astonishing advances made by the hardware engineering industry.  So the systems are getting twice as powerful, but they're not getting twice as fast at actually doing real stuff,  which means that the work they're doing is getting twice as complicated,  which means we are building more and more and more complicated systems,  and the complexity of those systems is doubling every few years.  Conway's law says that the systems will reflect the communication structures of the organizations that created them,  and Amdahl's law says that you have this upper limit on how effective your team sizes can be  if you have things like meetings and work that cannot be scaled and broken down.  So effectively, the message we can take,  the way that we can synthesize all of these laws into recommendations and things we can think about  is how we approach the task of building software differently.  We've got to get better at communicating asynchronously.  We've got to get better at interacting with teams and organizations.  The open source model kind of got this right almost from the word go.  How many people have went to a meeting for an open source project they work on?  Let alone a meeting at 9 o'clock in the morning where coffee and donuts are served, you know?  They got this distributed asynchronous, people do work when they're ready,  they retain information and statistics and people can work on it at their own time.  That model is going to become more and more widespread because in order to continue keeping pace  with the development of the systems we're building, we need bigger teams.  And there is a limit on how big teams get if you are doing things like having meetings.  So get rid of all the meetings, make a massive distributed team that's basically everybody in the world  and love the fact that everything you do is going to be running twice as fast in two years' time,  because you're going to be doing twice as much with it.  And I think we're going to stop it there. Thank you.  APPLAUSE  Are there any questions?  I love it when there's no questions.  It means you have all achieved complete enlightenment.  So yes, thank you all very much for coming.  Enjoy the last bit of the conference.  Staying around over the weekend, come to Pubcon on Saturday.  It's going to be awesome. Thank you very much for coming.
Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_0_59.png Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_60_107.png Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_108_20255.png Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_20256_27875.png Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_27876_29651.png Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_29652_40427.png Amdahl_to_Zipf_-_The_Physics_of_Software_-_Dylan_Beattie_40428_57494.png
All right, three o'clock, let's get started. Good afternoon, NDC. Before we get started, there are some things that you are not going to see in this talk, and I will tell you what they are right at the beginning, so if that's what you are here for, you can leave with no hard feelings. You will not see any code. You will not see any slides. You will not see any PowerPoint animations. And unfortunately, you will not see Peter. This talk was originally pitched as a... Peter Hinchins did a keynote at Coding Serbia last year, where he talked about the laws of physics as they are applied to software systems. And we were talking about this in a bar in Vilnius, and basically I loved this idea, and we started bouncing things backwards and forwards. It was really, really interesting. I said to him, why don't we do it at NBC Oslo as a double act? He said that sounds like a good idea for reasons those of you who know him will understand. He's not here. So, if you want to see PowerPoint, I believe they have some in the next room. I'm going to talk to you. I am going to talk to you about the laws of physics. There are all of these wonderful laws that people have discovered and refined and proposed and proved over the years. And some of these laws can apply to the software projects and the teams and the communities that we work in every day. I'm assuming most of the people here in this room were all developers of some sort or another. We worked on teams, we got stuff done, we built systems. And there are interesting observations about the way that we interact, because software is about people. And people are subject to the same physical laws that govern the universe we live in, just like everything else. And some of this is going to be fairly entertaining and high level, and some of it is actually going to be fairly specific. And we're going to do it in chronological order. Starting with Isaac Newton. Newton was a genius. Newton basically founded the principles of modern physics and mechanics. Newton was so smart that in the 16th century he came up with a set of laws which tell you why distributed software teams will fail. He just didn't know that's what he'd done until four centuries later when we looked it up and went, that's interesting. So Newton was a fascinating guy. He basically had three different careers. First he was a physicist or a natural scientist at the University of Cambridge, and he published the Principia Mathematica, or he basically laid out all these rules about how things work, how planets move, how gravity works, how all these kinds of things happen, how they behave, how to predict their influence. Then he became an alchemist for a while, and we don't talk about that very much, because he wasn't nearly as successful at turning lead into gold as he was at understanding planetary motion. And then he came to London and he ran the Royal Mint and did that for the last chapter of his life. So we're going to talk about Newton's Laws of Motion. So Newton's first law, which was published in Principia Mathematica in 1600 and something, basically says something that is at rest, something that's not moving, will not move. It will remain at rest until a force acts upon it, and something that is already moving will continue moving at a constant speed in a straight line until a force acts upon it. So there's a force that's not moving unless there is a force, a motive, an incentive for something to start happening. This is why when you wake up in the morning you think, I'm not going to move. I am at rest right now, and Newton says I should remain at rest. And then you remember that you have bills to pay, and if you don't get up and get online or go into your job or whatever, then you probably won't get paid. And so there is an economic motive, there is a force acting upon you, which will get you out of bed and get you moving. And the same thing is true of teams and companies. So, you know, organizations, startups will see an opportunity that will think, hey, we were talking in the show last night about the fact that the CEO of Uber doesn't have a driver's license. His driver's license expired, and the joke is that it's so Silicon Valley that when your driver's license expires, instead of getting a new one, you do a startup that will get people to pick you up from your door, because it's more fun and it's easier. So there are two kinds of force here. There's sort of attractive force. There's economic opportunity. There's seeing something and going, there is something here, we could go and do something, we could get rich, we could change the world, we could make this a better place. And then there is, if you like, the push force, the fear, where you're being driven to do something by, sometimes it's by threats from competition, sometimes it's legislative, sometimes it's, you need to do some work because a piece of your stack is like a ticking time bomb and you know that you're going to run out of a dress space or run out of capacity. So you have this idea of forces. Now, you ever worked in a company where they've been doing something happily for 10 years and you turn up and you try and change something and they're just like, no, no, we don't do that. This is not how we work, we do this. This is the same thing. Once they're moving in a straight line, they'll just keep trucking on. And Newton's Law is anyone who remembers studying them in high school, you always had these things in your examinations where it's like, you know, imagine a weight sliding down a smooth frictionless plane in a vacuum, which doesn't happen, you know, unless you're going ski jumping on the moon. But friction is a force and friction applies to real objects in the real world. It's why things slow down and friction applies to organizations as well. Even if you've got a team who are working and that, you know, the goal is focused, you're building a project, you have something to ship. Day by day, the kind of novelty and the initial push, you know, you will have the kickoff meeting where it's really exciting and it's inspiring and it's visionary. And a couple of weeks down the line, you're like, this isn't really quite as much fun as it used to be. And so it slows down because that organizational friction is a force. And that force will slow down the people and the teams that you're depending on to make these things happen. Newton's Second Law. This is the one you probably will remember from school. F equals MA. Force is mass times acceleration. Acceleration is how fast you can change something. You can change something by moving it very, very, very slowly, but to actually change direction. So acceleration is any change in direction. If you're moving, if you stop, that's an acceleration, negative acceleration. If you're standing still and you start moving, that's an acceleration. If you're going this way and you need to go that way, if you're running Mac, you need to switch to Windows. If you need to get everything from Pearl to Python, it's change of direction and that's an acceleration. And the force required to affect that acceleration scales with the size of the thing that you are trying to change. This is why startups can go, oh, hang on, this chat room that we've got, people are quite liking the fact they can share photographs on it. Let's turn our company into a photo sharing thing which has comments and that's how Flickr turned it from a chat service into an online photo album because they're small. They don't have a lot of mass. They don't have a lot of inertia. Startups can pivot really easily. You compare this to big organizations, Microsoft, Oracle, Sun Microsystems. These organizations are big. Start thinking about these in terms of super tankers, massive, massive, heavy structures that do not change direction easily. Now, the thing about F equals MA, you need to think about the time that it is going to take. You can steer a super tanker by very gently pushing for about six weeks and it will very slowly come about. If you want to do a handbrake turn in a super tanker, stuff is going to get broken because you are applying a massive force to affect a big acceleration on something which is massive. If you've ever, I'm sure there are people here who have been in organizations where somebody has used the fact that they are powerful to try and implement this kind of change. You get an email comes down from the CTO, from tomorrow there will be no more GitHub. We are using Team Source Safe for everything. They can do it because they are powerful so they can wield massive force. But trying to wield that force to a large organization to affect that change in a short space of time will break things. If they do this with enough authority behind them, sure, by the end of next week there will be no GitHub users left in the organization, but it's not necessarily because they've all gone and done the thing that you wanted them to do. It will be because they've left. So this is the equivalent, you know, visualize someone handbrake turning a super tanker into an iceberg. It's a very destructive mental picture, but when you are trying to affect large changes to large organizations in a very short space of time, that's effectively what you are trying to do. Newton's third law. For every action there is an equal and opposite reaction. This is the thing you push something, it pushes back. I'm standing here right now. I'm pushing down, Flora is pushing me back up. By happy coincidence they are exactly the same. I mean, that's why I can't fly, but it's also why I'm not sinking into the ground. You get this in organizations as well. You try and change something, there will be resistance. You propose something, people will push back at you. Hey, you know, I think we should stop sending out Word documents and we should do our updates on the Wiki. They'll be like, no, we don't like the Wiki. It's like, the Wiki is great. Everyone can read it. It's online. Anyone can edit it. I don't like anyone editing it. You get this reaction, it pushes back. The other interesting thing about the equal and opposite reaction is if you have one of these massive organizations, lots of inertia, lots of people, lots of money, you can use that as a springboard. Very, very small organizations, if they try and fire off something to go and explore a new opportunity or a new venture, it can actually, it can split the team because suddenly they don't have the bandwidth to cope anymore. But if you are, say, Microsoft, who are steaming along down the software industry with, you know, however many billion dollars in Windows and Office revenue behind you, and you suddenly realize that Sony and Nintendo and Sega are about to start winning the console war and you think it would be a great idea if Microsoft had a console, you can't steer the super tanker. Microsoft, the organization could not have pivoted to focus on games consoles as their primary area of business. But what they could do is leverage the mass that they had to spin off the Xbox division without worrying that that was going to disrupt what they were doing. You know, Xbox may have failed, but I don't think anyone would ever consider that spinning off a small team to go and develop a games console was an actual threat to Microsoft. You know, there's the marketing risk and there's the odd piece of brand fallout. But in terms of the core operation of that organization and the way that it works, the fact that they have that mass and that inertia allows them to spin things off against it at, you know, relatively little risk to what they're doing. So that's Newton's predictions about software teams and organizations written down in Latin in the 16th century. And, you know, here we are today exploring them and thinking about how they apply to what we're doing. There is another thing called the equivalency principle. The equivalency principle is an observation in physics that effectively says it is impossible to tell the difference between gravity and acceleration. You don't know if you're in orbit or you're falling until you hit the ground because you cannot distinguish as an observer, you cannot distinguish between acceleration that is because of gravity and acceleration that is because of a force that's being applied to it. Science fiction tropes love this. You ever read any of those books where they have the spacecraft that accelerates all the way so that there's gravity from the fact that the engines are pushing? And then when they get to the halfway point, the whole ship turns around and it does the rest of the journey in reverse and it's breaking the whole way. And so that acceleration and then breaking provides an artificial gravity for all the people who are on board. So an idea Arthur C. Clarke used a couple of times. Now the interesting thing about the equivalency principle is that it applies to observers within the frame of reference that you're talking about. There is a thing in aviation that's called a graveyard spiral. Now graveyard spiral is when you're flying in cloud, you can't see anything, your instruments are out and you think you are flying straight and level. And what you're actually doing is you are banking in a turn like this, but because the centripetal force from the turn feels just like gravity, you think you are in level flight. And because the gravity is coming from the turn, you're not conscious of the fact that you're falling. Now to somebody outside, it is completely obvious that you are not in level flight, you are doing this. Someone could see you on radar or something, they'd be like, hey, pull up, pull up, pull up, you know, you're in a deep problem situation here. The point about this is that from within our teams and within our organizations, it can be very, very difficult to tell whether we are doing the right things or not, until you hit the ground and realize that you've been falling all of this time. You know, projects where you're delivering code, you're working hard, you're shipping things, and then suddenly you realize that actually this is, you're not going to get out in time. Your version one product is targeting the wrong device. There are issues with your deployment strategy, something happens and splat, you know, you hit the ground, you face plant and things over. So the point about this, the equivalency principle is going to bite you because from inside it's impossible to tell the difference between being in a stable orbit and being in free fall. So you need external observations, you need somebody from outside who is looking in or, you know, observing what you are doing to allow you to tell the difference between these two scenarios. Which means you need to measure things, you need to set up some metrics. And the problem with measuring things is something called the uncertainty principle. So Werner Heisenberg has come over to say London from Germany, he's driving down the motorway, he's in his BMW, and because in Germany the Autobahn has no speed limit, he's, you know, got his foot down, he's going a feral clip and the police pull him over. And they say to him, you know, hello Mr. Heisenberg, do you know how fast you were going? And he says, no officer, but I know exactly where I was. And the policeman says, we just clocked you doing 120 miles an hour mate. And Heisenberg says, great, now I'm lost. Okay, so the people who were laughing know what the uncertainty principle is. Heisenberg basically observed that in subatomic physics, you cannot measure the position of a particle without affecting its velocity. So the more accurately you know the position, the less accurately you know how fast it's moving. And the more accurately you can measure how fast it's moving, the less accurately you know where it is. To measure more accurate velocity, you measure over a longer distance, which means you have more uncertainty around where the particle is during the measurement. To measure its position, the only way to do that is to bounce something off it. Imagine you've got like a soccer ball in a dark hall and you're trying to find out where it is by throwing golf balls. And sooner or later one of them is going to go ping and come back at you. But as you do that, the soccer ball is going to start rolling because someone just threw a golf ball at it. In software, we try and measure things all the time because it is very, very difficult in a lot of organizations and in a lot of programming methodologies and things to tell how good your progress is, to tell how well you are doing. Are you going to hit your deadline or not? And by trying to measure things about the way our systems work, you can actually interfere with them to the extent they stop working. A completely degenerate example of this, someone comes in and goes, look, this whole fixed salary thing is nonsense. We're going to pay you all per line of code. Software is code and we need code because we need to finish it. So from now on, at the end of every day, tell us how many lines of code you have written and we will pay you $1 for every line of code. How many people in here would be millionaires by the end of the morning? Because when they start measuring lines of code, you stop going, no, I'm not doing unit tests anymore. I'm just going to put new lines in. And then you can't, okay, I'm going to put empty statements. And you know, there's all sorts of measuring things. It's quite common in agile. One of the reasons why agile teams and scrum says you should estimate everything in points is because people used to estimate in hours. And then people would use the hours as a yardstick to measure them against. You said this ticket would take four hours. Why isn't it finished? You know, you started at one o'clock and I've checked in with you at two o'clock and three o'clock and four o'clock and five o'clock and it's still not done. And you're like, well, no, four hours was a sort of, if you add up all the tickets we do in a year and divide them by the number of tickets, you probably get some averages out, but these are not absolute accurate metrics. And there's all kinds of ways of measuring things. Anyone ever build websites and then go and run them through the W3C XHTML validator. So you get that green tick that says, you know, well done, good job. Your customers don't care if your HTML validates. The only person who cares about that is you. And there's nothing wrong with the sort of craftsmanship and professional pride. But never once have I had someone who's like, yeah, new product is ready. Customers want to buy it, but we're not shipping it because the HTML doesn't validate yet. So it doesn't matter. That's not the thing you should be measuring. Look at why you're there. What was the force that got you moving in the first place? How do you measure that, you know? If you're trying to be Uber, how many drivers, how many rides, how much revenue? If you're trying to be Spotify, how many bands, how many albums, how many streams, what is it you are trying to do? Because if you try and measure something else, you are going to end up affecting the team and the system that is trying to deliver something because they're going to start delivering the thing that's being measured because that's what they're being assessed on. You know, that's where the sense of value is coming from. So there you go. That's kind of the end of the deep theoretical physics stuff. It's going to get a little bit silly now. Murphy's Law. Murphy was, apocryphally, an engineer working in the United States Air Force in the 1960s. They were doing experiments with deceleration on rocket sleds. So they'd get a crash test dummy and they would put it in a chair on a sledge on a railway and they would put a rocket on the back of it and they'd smack it into a wall as hard as they could. And then they were like, down we didn't actually get any readings out of that. All we did is broke the dummy. So they come up with this idea of using strain gauges on all the seat belts so that when the thing crashed into the wall, they'd be able to tell afterwards how much strain each of the contact points on the harness had been subjected to. And John Stapp, I believe was his name, was the Earth Force Colonel conducting the experiment and Murphy was the guy who installed the strain meters. And the strain meters were symmetrical. They were physically symmetrical, but they only worked one way round. And he installed every single one of them backwards. And the phrase Murphy's Law was immortalized in a paper that Stapp wrote afterwards where depending which version of this you read and where the provenance comes from, is either if something can fail, it will fail, or if there's a way of getting it wrong, that bugger will do it. Murphy's Law is interesting because Murphy's Law is something that you want to keep in your head when you're thinking about user experience interaction and the way that you design and build your systems. So one of the sort of great examples of this is the old joke, when the inventor of USB dies, they're going to lower his coffin into the hole, stop, pick it up, turn it over, and lower it in again. USB is, so for starters, you get systems where you can actually destroy something. One of the interesting distinctions between the United Kingdom where I'm from and most of Europe is that you can't put our plugs, our mains plugs in upside down. With alternating current, it doesn't really matter because life neutral, neutral life, there aren't very many sort of consumer devices that are sensitive to that. But I always find it a bit interesting, you know, I have an extension cord where I put a European plug on a UK four-way brick so I can plug laptops and things in. I had to go and buy a Norwegian plug for it. And I opened the thing up and I'm like, which way around do you wire this? And it's like, actually it doesn't matter, you know. But if it did matter, then every time you plugged in a kettle or a laptop or anything in Europe you'd have a 50-50 chance of blowing it up. Because if the plug fits the wrong way around, and it shouldn't, now USB looks like it'll fit the wrong way around, but then you realize as you get in and there's actually a thing inside it that stops you inserting it backwards. Nine-volt batteries, little, you know, the PP3 batteries, the rectangular ones. You know they've got a little crown and they've got a little knobble on the top so that you can't connect them the wrong way around. It's exactly that, you know. If it matters which way around something is going to be done, make it impossible to get it wrong. Don't build a strain gauge that looks exactly the same until you crash it into a wall with a crash test dummy on it. The Apple Lightning connector, the one they use on the new iPhones, I think is a brilliant example of this because it works both ways. It's like a European plug. You know, it's a USB connector, but it doesn't matter if it's this way up or that way up so you can't get it wrong. You can't have that thing of scrabbling and going, yeah, it won't fit in having to turn over and do it the other way like you do with micro USB. The other thing where Murphy's Law is interesting is thinking about the interactions between your users and your systems because if somebody is going to... You're building an input, say, on a form and you're testing it. Somebody out there is going to do the wrong thing. Somebody is going to do it. The joke I love about this is a bad software tester walks into a bar. They order a beer, two beers, glass of wine, gin and tonic, packet of peanuts, chick, you know, it's good to go. The bar is ready. A good software tester walks into a bar. They order one beer, two beers, a glass of wine, minus one beers, a million beers, infinity beers, a lizard. Because they're testing the edge cases. Because it is all too common for us as developers. Because we have developed these mental models of the interaction models the systems were building, you have a picture in your head of what your user is like. And sometimes when you meet a real one, it can be a real shock because they are nothing at all like the person you had imagined was going to be using your system. So when you are testing, when you are developing, you know, systems and putting things together, don't always think, how can we make this right? Concentrate on the golden path by all means. If your users are smart, they are paying attention, they are doing the right thing, make that as seamless and painless and pleasant as possible. Because user experience is so fundamental to delighting users. But also think about what can go wrong. Because Murphy's law says if something can go wrong, it will eventually. There is a corollary that says it will also go wrong at the worst possible time. But, you know. Okay, so 10 laws of software development. We have Newton, 1, 2, 3. We have had the equivalency principle, we have had the uncertainty principle, we have had Murphy's law. Zipf's law. Zipf was a linguist and Zipf discovered something which is true and is freaky as hell and no one knows why it is the case. Zipf was analyzing the frequency of words in natural language, spoken language and written language. The most common word in English is the. The second most common word in English is of, which in any reasonable corpus of written English occurs about half as much. The third most common word is and. It occurs approximately one third as much. The 5,570th most common word in English is source. And it occurs almost exactly one 5,570th as often as the word the. There is this remarkable power law distribution of natural language and no one understands why this is the case. And when you start looking for it, you find that the same power law distribution starts cropping up in all kinds of places. If you look at the populations of large cities, the United States is a good example of this. The second most popular city has about half as many people as the first. The third most populace had about a third as many people. Fourth, and this distribution follows all the way down. And there is one theory that this is just, it's a product of the fact that we are human beings and we subconsciously as a, you know, society, as a group, we tailor and we optimize the things we have to worry about to keep them at a manageable scale. We want, you know, something which is infrequent. Naturally, we are wary of using it more often because it is infrequent. So it seems alien. The word there is very familiar. People use it readily because they're comfortable with it because they see it all the time. It's always there. It's omnipresent. A word like source, you need a more specialist application for. This 80-20 rule crops up all over the place. It occurs in code bases. If you look at the number of function calls and function routines and cyclomatic complexity of your code, then you'll find a similar parallel distribution. You'll have something at the top. You'll have something that's used about half as much, about a third as much. And this is very closely aligned to something called the Pareto principle, which is also known as the 80-20 rule, which also applies in all sorts of situations. Basically, 80% of your users will only ever use 20% of your features. Have you ever had the experience where you come into work on a Monday, or you sit down and work at home on a Monday, and by the end of the day, you're pretty much finished something? And then it takes you the whole rest of the week just to get the couple of bugs out and get it rendering in this one browser and work out why that unit test is failing? 20%, literally one day out of five. Monday, Tuesday, Wednesday, Thursday, Friday. And then Monday is the 20% of the time where you get 80% of the feature set done and delivered. And then it takes you the rest of the week to do all the little snagging edge cases that really aren't that important, but if you're going to ship the thing, they've got to be right. As I said, 80% of the bugs and defect reports in your software will come from 20% of the lines of code. I'm not going to go as far as saying that on Teams, 80% of the work is done by 20% of the people. But I'm sure some of you are thinking, hang on. And yeah, ZipSlau is, it's true. It holds true for all sorts of data sets and things. It's really interesting to think about when you're prioritizing and you're deciding the feature set and scale of the systems that you're going to build, but we don't know why it's the case. There's just something about things created by people that likes them to follow a power law distribution. And I would be fascinated if one day they actually find out why. So, seven laws, we're going to move on to the last three. The last three are where we start really talking about laws of software, as opposed to, you know, taking laws of physics and trying to make them fit and stuff. So the last three laws we want to talk about are Amdahl's law, Conway's law, and Moore's law. Amdahl's law is about the rate of improvement you can achieve in parallel computation by adding more resources to it. So, okay, good example. They say we're organizing a party. We have a nice big NDC after party tonight, and we need to prepare for it. And we've got, I don't know, 150 people in this room, 50 people in this room say. So we want to make a little bag with sweets and, you know, stickers and stuff for everybody, because it's not a party unless you get a little bag. And we need to go and pick up the cake. And the cake is in Sweden because we messed up the ordering. So we have a workload. We've got 50, say it takes 10 minutes to make one of these little party bags. So we've got 50 pieces of work that take 10 minutes each. So that's 500 minutes, 10 hours, give or take. And somebody needs to get a train to Sweden, which will take four hours, and pick up the cake and bring it back. Take another four hours. So if you, sir, I nominated you and said you're going to have to do all the work because when I did this is your party, you're going to have to do it. How long is it going to take you? So yeah, you've got, you know, 10 hours to make up all the party bags, and then eight hours to get to Sweden, bring the cake back. So you're looking at 18 hours. Say, take short days, long lunches, call it three days worth of work. Get someone to help you. So you say, come on, let's help out. You're going to make half of the party bags here. So you're going to make 25, you're going to make 25. So suddenly you've reduced the workload involved. You can do a day and you can do a day. You've got all the bags made, and then someone has to go and pick up the cake. So someone says, well, this is good. Why don't we get someone else to go and pick up the cake while we make party bags? So we'll get you to help out. So you go to Sweden, pick the cake up. Bang, we've gone from three days to two days to one day. You, you, you, you, you, you, you, you, you, you. Everyone here all decide they're all going to pitch in and make party bags. How long is it going to take? One day. There is no way adding more people can achieve that in less than a day because we have a piece of time-bound work that cannot be parallelized. There is no way that someone can bring the cake back while someone is on the train to Sweden to pick it up. And this, what it does is it imposes an upper limit on the number of effective cause threads, processes that will give you any improvement in how a piece of work is being done. There's a lot of work. So Moore's Law, the other one we're talking about here, Gordon Moore worked for Intel. I'm sure you're all familiar with Moore's Law. He basically had said that computers get twice as fast for the same money every 18 months. Originally his observation was, this was back in the early 1980s I think, and he observed that the number of transistors you could fit on the same piece of silicon was doubling every 18 months. And he thought this would probably be true for about another two or three years. It has proved to be true for two or three decades. You know, it was absolutely spot on. And because so much systems design an interaction and system capability scales directly with the amount of processing power, which is the number of transistors you can fit on a silicon wafer, basically computers get twice as fast every 18 months for the same price. So on the one hand we have systems becoming more and more powerful in terms of the amount of parallelism they can do. On the other hand we have Amdahl's Law which imposes limits on how much computation you can actually, how much of an improvement you can get by adding more process to it. Now what's interesting with Amdahl's Law is think about it in terms of people. So go back to our example there. So there we've got a project that we cannot parallelize. There is no way we can organize a party, you know, it's hop us three now, the conference finishes it, hop us six. There's no way we can have our party ready to go in three hours, no matter how many people we hire to help us organize it. If you are working on a software team and you have activities which cannot be parallelized and are time bound, they impose an upper limit on how much faster you can go by adding more people to it. The classic example of this is meetings. If you have eight hours worth of meetings that are necessary because that's how your project works, there is no way you can hire enough people to do that project in less than eight hours. So it imposes an upper limit on take the total amount of time you've got 20 days of work to do except two days of the meetings. You can get 10 people on that team, but the 11th person will have nothing to do because the meetings are happening and everyone else is already busy. And that's it. All of the work is being taken care of. All your tickets are in flight. Everything is already happening. So these patterns of locking components, if you think about distributed system design, so imagine for one second that we had an online commerce website. The customer is going to connect to our website. They are going to place an order. We're going to talk to the inventory system, determine that we've got that particular type of, I don't know, NDC party cake, ordering a cake online because we're not going to go to Sweden. So we go on, we order the cake, check with the inventory. Do we have the cake? Yes. Respond. Check with the account system. Is this customer validated? Yes. Okay. Do you have a message to the warehouse system? Please ship this cake to this address. Yes. And then send a response back. And those systems may take, you know, three, four, five seconds to recover. But what we're going to do, whenever anyone hits our website, we are going to set up a massive distributed transaction and take an atomic lock on every single component in the entire system until all of them, they are not allowed to deal with any other requests or process any other work. So whilst we're ordering the cake, the website is effectively down for everyone else in the world. The inventory warehouse system is down for everyone else in the world. The stock control system is down. The delivery system is down. We look at it like that. It seems absolutely crazy, doesn't it? No one would ever build software like that. But you'll call half a dozen people into a room and sit them down to have a meeting and say, none of you can do anything else for the next two hours. We are getting very, very good at modeling distributed systems in terms of autonomous actors that have their own workload, they have their own inputs, they have their own outputs, and they can deal with the work that comes to them as effectively as possible, and these systems are easy to scale up. And this brings us on to the tenth of the laws we're talking about today, which is Conway's law. Mel Conway observed in 1964 that organizations that create systems will tend to create systems that reflect the communication structures of the organizations that build them. This is something that I've done a lot of thinking, a lot of research, and a lot of speaking about. Peter Hinchin summarized this as, if you have shit people, you'll have shit code, which is a fairly pithy kind of synopsis of how it works. What it means is if you've got two teams who, for whatever reason, communicate amongst themselves better than they communicate with the other team, you're going to end with two very tightly coupled components with some kind of interface layer between them that doesn't work quite so well. If you've got three or four or five teams, you're going to end up with three or four or five different components. If you've got teams that talk to each other very readily, then the interface between those two teams is going to be good. It's going to be fit for purpose, because those people will communicate. If you've got two teams who are very bad at maintaining the boundary, you are going to get tight coupling, because two components that were supposed to be separate end up being bound together. So we have these three laws. We have Moore's law, which says that systems are getting cheaper, computation is getting cheaper, everything is getting more expensive. When I first started doing software development, I probably spent about an hour a day waiting for my PC to do things. Now I probably spend about an hour a day waiting for my PC to do things, because we're not using all of this amazing computing power to do the same things quicker. We're using it to do more things. The fact that the amount of time you spend interacting with the system remain constant must mean that the complexity of the systems we are building is doubling. There is a lovely quote, the greatest achievement of the software engineering industry is to completely neutralize the astonishing advances made by the hardware engineering industry. So the systems are getting twice as powerful, but they're not getting twice as fast at actually doing real stuff, which means that the work they're doing is getting twice as complicated, which means we are building more and more and more complicated systems, and the complexity of those systems is doubling every few years. Conway's law says that the systems will reflect the communication structures of the organizations that created them, and Amdahl's law says that you have this upper limit on how effective your team sizes can be if you have things like meetings and work that cannot be scaled and broken down. So effectively, the message we can take, the way that we can synthesize all of these laws into recommendations and things we can think about is how we approach the task of building software differently. We've got to get better at communicating asynchronously. We've got to get better at interacting with teams and organizations. The open source model kind of got this right almost from the word go. How many people have went to a meeting for an open source project they work on? Let alone a meeting at 9 o'clock in the morning where coffee and donuts are served, you know? They got this distributed asynchronous, people do work when they're ready, they retain information and statistics and people can work on it at their own time. That model is going to become more and more widespread because in order to continue keeping pace with the development of the systems we're building, we need bigger teams. And there is a limit on how big teams get if you are doing things like having meetings. So get rid of all the meetings, make a massive distributed team that's basically everybody in the world and love the fact that everything you do is going to be running twice as fast in two years' time, because you're going to be doing twice as much with it. And I think we're going to stop it there. Thank you. APPLAUSE Are there any questions? I love it when there's no questions. It means you have all achieved complete enlightenment. So yes, thank you all very much for coming. Enjoy the last bit of the conference. Staying around over the weekend, come to Pubcon on Saturday. It's going to be awesome. Thank you very much for coming.
not here. So, if you want to see PowerPoint, I people are subject to the same physical laws that everything else. And some of this is going to be we're going to talk about Newton's Laws of And that force will slow down the people and the equals MA, you need to think about the time that exploring them and thinking about how they apply that from within our teams and within our ways. It's like a European plug. You know, it's a to be using your system. So when you are testing, build, but we don't know why it's the case. everyone else in the world. The inventory the greatest achievement of the software