Amdahl to Zipf: The Physics of Software
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51695 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Forcing (mathematics)PhysicalismPosition operatorGravitationInteractive televisionState observerPhysical systemDifferent (Kate Ryan album)Office suiteDisk read-and-write headRoundness (object)Revision controlMultiplication signLimit (category theory)MetreMetric systemNeuroinformatikTask (computing)Endliche ModelltheorieOrbitTheoryPoint (geometry)Distribution (mathematics)BitCASE <Informatik>Lattice (order)Message passingInfinityPhysical lawStrategy gameSoftware testingProduct (business)Musical ensembleTheory of everythingStreaming mediaGoodness of fitPower (physics)Letterpress printingDevice driverÄquivalenzprinzip <Physik>SoftwareCodeSoftware industryValidity (statistics)Process (computing)outputSimilarity (geometry)Projective planeUncertainty principleQuicksortLine (geometry)Complex (psychology)Wave packetBuildingModern physicsWebsiteCycle (graph theory)WorkloadUniverse (mathematics)WordGraph coloringCoroutineStatement (computer science)Functional (mathematics)EstimatorFrequencySystem callFitness functionLaptopFormal language1 (number)Bit rateInterface (computing)Self-organizationComponent-based software engineeringTelecommunicationData structureSoftware developerLevel (video gaming)Order (biology)Term (mathematics)Function (mathematics)Point cloudStatisticsExtension (kinesiology)Computer programSpiralArithmetic progressionControl flowInformationFrame problemAutonomic computingUniform boundedness principleVideo gameMeasurementArithmetic meanPrincipal idealParticle systemDistanceWhiteboardVelocityReverse engineeringInsertion lossConcentric2 (number)MathematicsFrictionOperator (mathematics)MassNumberObject (grammar)CuboidDependent and independent variablesDivision (mathematics)Direction (geometry)Channel capacityVacuumPlanningGame theoryWeightCore dumpSpecial unitary groupTrailAreaSpacetimeDressing (medical)Address spaceUltraviolet photoelectron spectroscopyBand matrixOracleWindowMoment of inertiaDigital photographyService (economics)Scaling (geometry)Sound effectShared memoryGroup actionWikiBoundary value problemZipf's lawMilitary baseOpen sourceSweep line algorithmRule of inferencePhysicistSet (mathematics)Mechanism designEquivalence relationType theoryCartesian coordinate systemControl systemNegative numberMoore's lawComputer engineeringSoftware engineeringTraffic reportingAtomic clockSlide ruleCategory of beingPattern languageParallel computingSoftware bugCausalityThread (computing)Natural languageLatin squareUnit testingTotal S.A.EmailPredictabilityPlug-in (computing)Online chatVisualization (computer graphics)AuthorizationReal numberSega Enterprises Ltd.Nintendo Co. Ltd.Right angleReading (process)Pareto distributionNatural numberParallel portCodeForceDevolution (biology)Newton, IsaacInheritance (object-oriented programming)World Wide Web ConsortiumAverageOptical disc driveFlickrVideo game consoleJSON
Transcript: English(auto-generated)
00:04
All right, 3 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 were here for, you can leave with no hard feelings.
00:21
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 Hynchins did a keynote at Coding Serbia last year, where he talked about the laws of physics
00:40
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 NDC 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.
01:03
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
01:20
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 get stuff done. We build systems.
01:42
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.
02:01
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.
02:21
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 where he basically laid out all these rules about how things work, how planets move,
02:41
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 sort of last chapter of his life.
03:01
But we're gonna 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.
03:21
And something that is already moving will continue moving at a constant speed in a straight line until a force acts upon it. Things don't happen 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 gonna move.
03:42
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.
04:02
And the same thing is true of teams and companies. So organizations, startups will see an opportunity. They'll 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,
04:20
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,
04:43
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 gonna run out of address space or run out of capacity. So you have this idea of forces.
05:01
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 Laws, anyone who remembers studying them in high school, you always had these thing in your examinations where it's like,
05:22
imagine a weight sliding down a smooth, frictionless plane in a vacuum, which doesn't happen 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
05:41
and 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've all had 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
06:01
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 all remember from school. So F equals MA. Force is mass times acceleration. Acceleration is how fast you can change something.
06:22
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,
06:41
if you need to get everything from Perl to Python, it's a change of direction and that's an acceleration. And the force required to effect 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,
07:01
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,
07:21
these organizations are big. You know, I start thinking about these in terms of super tankers. You know, 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
07:42
for about six weeks and it will very slowly come about. If you wanna do a handbrake turn in a super tanker, stuff is gonna get broken because you are applying a massive force to effect a big acceleration on something which is massive. And if you've ever, I'm sure there are people here
08:01
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 SourceSafe for everything. And they can do it because they are powerful
08:21
so they can wield massive force. But trying to wield that force to a large organization to effect that change in a short space of time will break things. If they do this with enough authority behind them, sure, you know, 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
08:41
and done the thing that you wanted them to do. It'll 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're trying to effect large changes to large organizations in a very short space of time, that's effectively what you're trying to do.
09:02
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, floor is pushing me back up. By happy coincidence, they're exactly the same. I mean, this is why I can't fly but it's also why I'm not sinking into the ground.
09:21
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. No, we're like, no, we don't like the Wiki. It's like, the Wiki's great, everyone can read it. It's online, anyone can edit it. Oh, I don't like anyone editing it. You get this reaction, it pushes back.
09:42
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
10:01
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 however many billion dollars in Windows and Office revenue behind you, and you suddenly realize that Sony and Nintendo and Sega
10:23
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 supertanker. 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
10:42
to spin off the Xbox division without worrying that that was going to disrupt what they were doing. 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. There's the marketing risk
11:00
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 relatively little risk to what they're doing. So that's Newton's predictions about software teams and organizations
11:21
written down in Latin in the 16th century. And 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.
11:43
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
12:02
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. It's an idea Arthur C. Clarke used a couple of times.
12:20
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 cloud, you can't see anything, your instruments are out and you think you are flying straight and level.
12:41
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.
13:02
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
13:20
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 gonna 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,
13:40
you hit the ground, you face plant and the thing's over. So the point about this, the equivalency principle is gonna 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.
14:02
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 is, has come over to say London from Germany. He's driving down the motorway. He's in his BMW.
14:20
And because in Germany, the Autobahn has no speed limit, he's, you know, got his foot down. He's got a feral clip and the police pull him over. 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,
14:41
we just caught you doing 120 miles an hour, mate. And Heisenberg says, well, great, now I'm lost. Okay, so the people that 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.
15:01
So the more accurately you know the position, the less accurate 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.
15:22
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 gonna go bing and come back at you. But as you do that, the soccer ball is gonna start rolling because someone just threw a golf ball at it. In software, we try and measure things all the time
15:40
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 gonna hit your deadline or not? And by trying to measure things about the way our systems work,
16:00
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 gonna 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.
16:21
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 gonna put new lines in and then you can't, okay, I'm gonna put empty statements. And there's all sorts of measuring things.
16:41
It's quite common in agile. One of the reasons why agile teams and scrums 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 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.
17:01
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'll 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,
17:22
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 this craftsmanship and professional pride, but never once have I had someone who's like, yeah, new product is ready, customers wanna buy it, but we're not shipping it because the HTML doesn't validate yet. So it doesn't matter.
17:41
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? 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?
18:01
Because if you try and measure something else, you are gonna end up affecting the team and the system that is trying to deliver something because they're gonna start delivering the thing that's being measured because that's what they're being assessed on. That's where the sense of value is coming from. So there you go, that's kind of the end
18:22
of the deep theoretical physics stuff. It's gonna get a little bit silly now. Murphy's Law. Murphy was apocryphally a 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
18:40
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, Dan, we didn't actually get any readings out of that. All we did is broke the dummy. So they came 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
19:00
each of the contact points on the harness had been subjected to. And John Stapp, I believe was his name, was the Air 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.
19:21
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.
19:44
Murphy's Law is interesting because Murphy's Law is something that you wanna 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, you know, when the inventor of USB dies,
20:01
they're gonna 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,
20:22
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, and I had to go and buy a Norwegian plug for it.
20:41
And I open 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
21:01
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 gonna be done,
21:20
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.
21:40
So you never again have that thing of scrabbling and going, it won't fit and 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,
22:01
somebody out there is gonna do the wrong thing. Somebody is gonna 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, 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,
22:21
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 we're building. You have a picture in your head
22:40
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 and 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. Make it, if your users are smart,
23:01
they're paying attention, they're 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 also go wrong
23:21
at the worst possible time, but you know. Okay, so 10 laws of software development. We've had Newton one, two, three. We've had the equivalency principle. We've had the uncertainty principle. We've had Murphy's law. Zipf's law. Zipf was a linguist and Zipf discovered
23:42
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.
24:01
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 5570th most common word in English is source
24:22
and it occurs almost exactly one 5570th 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
24:41
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 populous city has about half as many people as the first. The third most populous 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,
25:01
it's a product of the fact that we are human beings and we subconsciously as a 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 something which is infrequent. Naturally, we are wary of using it more often
25:20
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. And this 80 20 rule crops up all over the place. It occurs in code bases. If you look at the number of function calls
25:40
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.
26:01
Basically 80% of your users will only ever use 20% of your features. 80% of the, have you ever had the experience where you come into work on a Monday or you sit down, 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
26:20
and work out why that unit test is failing? 20%, literally one day out of five. Monday, Tuesday, Wednesday, Thursday, Friday. 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 gonna ship the thing, they've gotta be right.
26:41
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 gonna 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. So, and yeah, Zipf's law is,
27:03
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
27:21
if one day they actually find out why. So, seven laws. We're gonna 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 wanna talk about
27:40
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 of this. Say we're organizing a party. We're gonna have a nice big NDC after party tonight,
28:02
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 wanna 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.
28:22
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.
28:41
So, if you, sir, I nominated you and said, you're gonna have to do all the work, because this is your party, you're gonna have to do it. How long is it gonna take you? So, yeah, you've got 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.
29:00
Say, take short days, long lunches, call it three days worth of work. Get someone to help you. So, you, sir, you're like, come on, let's help out. You're gonna make half of the party bags here. So, you're gonna make 25, you're gonna 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 bags made, and then someone has to go and pick up the cake.
29:22
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, everyone here, all decide they're all gonna pitch in and make party bags. How long is it gonna take?
29:43
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.
30:02
And this, what it does is it imposes an upper limit on the number of effective cores, 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,
30:20
Gordon Moore worked for Intel. I'm sure you're all familiar with Moore's Law. Basically, it 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.
30:40
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. It was absolutely spot on. And because so much systems design and 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,
31:02
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
31:21
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 half past three now. The conference finishes at half past 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.
31:43
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, yeah?
32:01
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. And 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 them are meetings. You can get 10 people on that team,
32:20
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 a online commerce website.
32:43
Customer is gonna connect to our website. They are going to place an order. We're gonna 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 gonna go to Sweden. So, we go and we order the cake, check with the inventory. Do we have the cake? Yes.
33:00
Respond. Check with the account system. Is this customer validated? Yes. Okay. Send 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 gonna 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
33:22
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 warehouse system is down for everyone else in the world. The stock control system is down. The delivery system is down. When you look at it like that, it seems absolutely crazy, doesn't it?
33:41
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
34:03
as effectively as possible, and these systems are easy to scale up. And this brings us on to the 10th 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
34:21
of the organizations that built them. This is something that I've done a lot of thinking, a lot of research, and a lot of speaking about. Peter Hynchon 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
34:40
who, for whatever reason, communicate amongst themselves better than they communicate with the other team, you're gonna end up 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, four, five teams, you're gonna 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
35:00
between those two teams is gonna be good, it's gonna 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 gonna 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,
35:21
computation is getting cheaper, everything is getting more expensive. And 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.
35:42
And so 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.
36:02
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 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
36:20
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, you know, the way that we can synthesize all of these laws into recommendations
36:40
and things we can think about and how we do 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 ever went to a meeting for an open source project they work on?
37:01
Let alone a meeting at nine 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, we maintain information and statistics and people can work on it in their own time. That model is gonna become more and more widespread because in order to continue keeping pace with the development of the systems we're building,
37:21
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 gonna be running twice as fast in two years time but it won't matter because you're gonna be doing twice as much with it. And I think we're gonna stop it there.
37:42
Thank you. Are there any questions? I love it when there's no questions. Means you have all achieved complete enlightenment.
38:00
So yes, thank you all very much for coming. Enjoy the last bit of the conference. If you're staying around over the weekend, come to PubConf on Saturday, it's gonna be awesome. Thank you very much for coming.