Good after­noon, NDC. Before we get start­ed, 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 begin­ning so if that’s what you’re here for, you can leave with no hard feel­ings. You will not see any code. You will not see any slides. You will not see any PowerPoint ani­ma­tions. And unfor­tu­nate­ly you will not see Pieter. 

This talk was orig­i­nal­ly pitched as a… Pieter Hintjens did a keynote at Coding Serbia last year where he talked about the laws of physics as they are applied to soft­ware sys­tems. And we were talk­ing about this in a bar in Vilnius. And basi­cal­ly I loved this idea and we start­ed bounc­ing things back­wards and for­wards. It was real­ly real­ly inter­est­ing. I said to him why don’t we do it at NDC Oslo as a dou­ble act. He said that sounds like a good idea. For rea­sons those of you know him well under­stand, he’s not here. So, if you want to see PowerPoint, I believe they have some in the next room. 

I am going to talk to you about the the laws of physics. There are all of these won­der­ful laws that peo­ple have dis­cov­ered and refined and pro­posed and proved over the years. And some of these laws can apply to the soft­ware projects and the teams and the com­mu­ni­ties that we work in every day. I’m assum­ing most of the peo­ple here in this room, we’re all devel­op­ers of some sort or anoth­er. We worked on teams, we get stuff done, we build sys­tems. And there are inter­est­ing obser­va­tions about the way that we inter­act. Because soft­ware is about peo­ple, and peo­ple are sub­ject to the same phys­i­cal laws that gov­ern the uni­verse we live in, just like every­thing else. And some of this is going to be fair­ly enter­tain­ing and high-level, and some of it is actu­al­ly going to be fair­ly specific.

And we’re going to do it in chrono­log­i­cal order, start­ing with Isaac Newton. Newton was a genius. Newton basi­cal­ly found­ed the prin­ci­ples of mod­ern physics and mechan­ics. Newton was so smart that in the 16^th cen­tu­ry he came up with a set of laws which tell you why dis­trib­uted soft­ware teams will fail. He just did­n’t know that’s what he’d done until four cen­turies lat­er when we looked it up and went, ​“That’s interesting…”

So Newton was a fas­ci­nat­ing guy. He basi­cal­ly had three dif­fer­ent careers. First he was a physi­cist, or a nat­ur­al sci­en­tist, at the University of Cambridge. And he pub­lished the Principia Mathematica, where he basi­cal­ly laid out all these rules about how things work. How plan­ets move. How grav­i­ty works. How all these kinds of things hap­pen. How they behave. How to pre­dict their influ­ence. Then he became an alchemist for a while. And we don’t talk about that very much because he was­n’t near­ly as suc­cess­ful at turn­ing lead into gold as he was at under­stand­ing plan­e­tary motion. And then he came to London and he ran the Royal Mint, and did that for the sort of last chap­ter of his life.

But we’re going to talk about Newton’s laws of motion. So, Newton’s First Law, which was pub­lished in the Principia Mathematica in 1600 and some­thing basi­cal­ly says, some­thing that is at rest, some­thing that’s not mov­ing, will not move. It will remain at rest until a force acts upon it. And some­thing that is already mov­ing will con­tin­ue mov­ing at a con­stant speed in a straight line until a force acts upon it.

Things don’t hap­pen unless there is a force, a motive, an incen­tive, for some­thing to stop hap­pen­ing. This is why when you wake up in the morn­ing you think, ​“I’m not gonna move. I am at rest right now and Newton says I should remain at rest.” And then you remem­ber that you have bills to pay, and if you don’t get up and get online or go into your job or what­ev­er, then you prob­a­bly won’t get paid. And so there is an eco­nom­ic motive. There is a force act­ing upon you which will get you out of bed and get you moving.

And the same thing is true of teams and com­pa­nies. So you know, orga­ni­za­tions, star­tups, will see an oppor­tu­ni­ty. They’ll think hey, we were talk­ing in the show last night about the fact that the CEO of Uber does­n’t have a dri­ver’s license. His dri­ver’s license expired. And the joke is that it’s so Silicon Valley that when your dri­ver’s license expires, instead of get­ting a new one you do a start­up that will get peo­ple 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 attrac­tive force. There’s eco­nom­ic oppor­tu­ni­ty. There’s see­ing some­thing and going, ​“There’s some­thing here.” We could go and do some­thing. We could get rich. We could change the world. We could make this a bet­ter place. And then there is, if you like, the push force, the fear, where you’re being dri­ven to do something—sometimes it’s by threats from com­pe­ti­tion, some­times its leg­isla­tive, some­times ts you need to do some work because a piece of your stack is like a tick­ing time bomb and you know that you’re going to run out of address space or run out of capacity.

So you have this idea of forces. Now, you ever worked in a com­pa­ny where they’ve been doing some hap­pi­ly for ten years and you turn up and you try and change some­thing 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 mov­ing in a straight line, they’ll just keep truck­ing on. And Newton’s laws, any­one who remem­bers study­ing them in high school, you always had these thing in your exam­i­na­tions where it’s like ​“imag­ine a weight slid­ing down a smooth fric­tion­less plane in a vac­u­um.” Which…doesn’t hap­pen, you know. Unless you’re going ski jump­ing on the moon. 

But fric­tion is a force. And fric­tion applies to real objects in the real world. It’s why things slow down. And fric­tion applies to orga­ni­za­tions as well. Even if you’ve got a team who are work­ing and the goal is focused, you’re build­ing a project, you have some­thing to ship. Day by day, the kind of nov­el­ty and the ini­tial push— You know, you’ve all had the kick-off meet­ing where it’s real­ly excit­ing and it’s inspir­ing and it’s vision­ary. And a cou­ple of weeks down the line you’re like this isn’t real­ly quite as much fun as it used to be. And so it slows down. Because that orga­ni­za­tion­al fric­tion is a force. And that force will slow down the peo­ple and the teams that you’re depend­ing on to make these things happen.

Newton’s Second Law. This is the one you prob­a­bly all remem­ber from school, ​“F=ma”. Force is mass times accel­er­a­tion. Acceleration is how fast you can change some­thing. You can change some­thing by mov­ing it very very very slow­ly. But to actu­al­ly change direc­tion— So, accel­er­a­tion is any change in direc­tion. If you’re mov­ing, if you stop that’s an accel­er­a­tion; neg­a­tive accel­er­a­tion. If you’re stand­ing still and you start mov­ing, that’s an accel­er­a­tion. If you’re going this way and you need to go that way; if you’re run­ning Mac you need to switch to win­dows; if you need to get every­thing from Perl to Python it’s a change of direc­tion. And that’s an acceleration.

And the force required to effect that accel­er­a­tion scales with the size of the thing that you are try­ing to change. This is why star­tups can go, ​“Ooh, hang on. This chat room that we’ve got, peo­ple are quite lik­ing the fact they can share pho­tographs on it. Let’s turn our com­pa­ny into a photo-sharing thing which has com­ments.” And that’s how Flickr turned from a chat ser­vice into an online pho­to album. Because they’re small. They don’t have a lot of mass, they don’t have a lot of inertia.

Startups can piv­ot real­ly eas­i­ly. You com­pare this to big orga­ni­za­tions, Microsoft, Oracle, Sun Microsystems. These orga­ni­za­tions are big. Start think­ing about these in terms of super­tankers. Massive, mas­sive, heavy struc­tures, that do not change direc­tion eas­i­ly. Now the thing about F=ma, you need to think about the time that it is going to take. You can steer a super­tanker by very gen­tly push­ing for about six weeks, and it will very slow­ly come about. If you want to do a hand­brake turn in a super­tanker, stuff is going to get bro­ken. Because you are apply­ing a mas­sive force to effect a big accel­er­a­tion on some­thing which is massive.

And if you’ve ever— I’m sure there are peo­ple here who have been in orga­ni­za­tions where some­body has used the fact that they are pow­er­ful to try and imple­ment this kind of change… You get an email comes down from the CTO, ​“From tomor­row there will be no more Github, We are using SourceSafe for every­thing.” And they can do it because they are pow­er­ful, so they can wield mas­sive force. But try­ing to wield that force to a large orga­ni­za­tion to effect that change in a short space of time will break things. If they do this with enough author­i­ty behind them sure, by the end of next week there will be no Github users left in the orga­ni­za­tion. But it’s not nec­es­sar­i­ly because they’ve all gone and done the thing that you want­ed them to do. It’ll be because they’ve left.

So this is the equivalent—you know, visu­al­ize some­one handbrake-turning a super­tanker into an ice­berg. It’s a very destruc­tive men­tal pic­ture, but when you’re try­ing to effect large changes to large orga­ni­za­tions in a very short space of time, that’s effec­tive­ly what you’re try­ing to do.

Newton’s Third Law, for every action there is an equal and oppo­site reac­tion. This is the thing, you push some­thing, it push­es back. I’m stand­ing here right now. I’m push­ing down, floors push­ing me back up. By hap­py coin­ci­dence, they’re exact­ly the same. It’s why I can’t fly but it’s also why I’m not sink­ing into the ground.

You get this in orga­ni­za­tions as well. You try and change some­thing, there will be resis­tance. You pro­pose some­thing, peo­ple will push back at you. ​“Hey you know, I think we should stop send­ing out Word doc­u­ments and we should do our updates on the wiki.” 

They’ll be like, ​“No, we don’t like the wiki.”

It’s like, ​“The wik­i’s great. Everyone can read it. It’s online. Anyone can edit it.”

“Oh, I don’t like any­one edit­ing it.”

You get this reaction that push­es back.

The oth­er inter­est­ing thing about the equal and oppo­site reac­tion is if you have one of these mas­sive orga­ni­za­tions, lots of iner­tia, lots of peo­ple, lots of mon­ey, you can use that as a spring­board. Very very small orga­ni­za­tions, if they try and fire off some­thing to go and explore a new oppor­tu­ni­ty or a new ven­ture, it can actu­al­ly split the team. Because sud­den­ly they don’t have the band­width to cope anymore. 

But if you are say, Microsoft, who are steam­ing along down the soft­ware indus­try with how­ev­er many bil­lion dol­lars in Windows and Office rev­enue behind you, and you sud­den­ly real­ize that Sony and Nintendo and Sega are about to start win­ning the con­sole war and you think it would be a great idea if Microsoft had a con­sole… You can’t steer the super­tanker. Microsoft the orga­ni­za­tion could not have piv­ot­ed to focus on games con­soles as their pri­ma­ry area of business.

But what they could do is lever­age the mass that they had to spin off the Xbox divi­sion with­out wor­ry­ing that that was going to dis­rupt what they were doing. Xbox may have failed, but I don’t think any­one would ever con­sid­er that spin­ning off a small team to go and devel­op a games con­sole was an actu­al threat to Microsoft. There’s the mar­ket­ing risk and there’s the odd piece of brand fall­out, but in terms of the core oper­a­tion of that orga­ni­za­tion and the way that it works, the fact that they have that mass and that iner­tia allows them to spin things off against it at rel­a­tive­ly lit­tle risk to what they’re doing. 

So that’s Newton’s pre­dic­tions about soft­ware teams in orga­ni­za­tions, writ­ten down in Latin in the 16^th cen­tu­ry. And here we are today explor­ing them and think­ing about how they apply to what we’re doing. 

There is then a thing called the equiv­a­len­cy prin­ci­ple. The equiv­a­len­cy prin­ci­ple is an obser­va­tion in physics that effec­tive­ly says it is impos­si­ble to tell the dif­fer­ence between grav­i­ty and accel­er­a­tion. You don’t know if you’re in orbit or your falling, until you hit the ground. Because you can­not dis­tin­guish— As an observ­er, you can­not dis­tin­guish between accel­er­a­tion that is because of grav­i­ty, and accel­er­a­tion that is because of a force that’s being applied to it. 

Science fic­tion tropes love this. You ever read any of those books where they have the space­craft that accel­er­ates all away so that there’s grav­i­ty from the fact that the engines are push­ing? And then when they get to the halfway point, the whole ship turns round and it does the rest of the jour­ney in reverse and it’s break­ing the whole way? And so that accel­er­a­tion and then break­ing pro­vides an arti­fi­cial grav­i­ty for all the peo­ple who are on board. It’s an idea Arthur C. Clarke used a cou­ple of times. 

Now, the inter­est­ing thing about the equiv­a­len­cy prin­ci­ple is that it applies to observers with­in the frame of ref­er­ence that you’re talk­ing about. There is a thing in avi­a­tion that’s called a grave­yard spi­ral. Now, a grave­yard spi­ral is when you’re fly­ing in a cloud, you can’t see any­thing, your instru­ments are out, and you think you are fly­ing straight and lev­el. And what you’re actu­al­ly doing is you are bank­ing in a turn like this. But because the cen­tripetal force from the turn feels just like grav­i­ty, you think you are in lev­el flight. And because the grav­i­ty is com­ing from the turn, you’re not con­scious of the fact that you’re falling.

Now, to some­body out­side it is com­plete­ly obvi­ous that you are not in lev­el flight, you are doing this. [indi­cates a down­ward spi­ral] Someone could see you on radar or some­thing, they’d be like, ​“Hey. Pull up pull up pull up. You’re in a deep prob­lem sit­u­a­tion here.” The point about this is that from with­in our teams and with­in our orga­ni­za­tions it can be very very dif­fi­cult to tell whether we are doing the right things or not, until you hit the ground and real­ize that you’ve been falling all of this time.

Projects where you’re deliv­er­ing code, you’re work­ing hard, you’re ship­ping things… And then sud­den­ly you real­ize that actu­al­ly you’re not going to get out in time; your ver­sion one prod­uct is tar­get­ing the wrong device; there are issues with your deploy­ment strat­e­gy; some­thing hap­pens and…splat. You hit the ground, you face­plant, and the things over.

So the point about this, the equiv­a­len­cy prin­ci­ple is going to bite you because from inside it’s impos­si­ble to tell the dif­fer­ence between being in a sta­ble orbit and being in freefall. So you need exter­nal obser­va­tions. You need some­body from out­side who is look­ing in or observ­ing what you are doing to allow you to tell the dif­fer­ence between these two scenarios. 

Which means you need to mea­sure things. You need to set up some met­rics. And the prob­lem with mea­sur­ing things. Is some­thing called the Uncertainty Principle. So, Werner Heisenberg has come over to say, London, from Germany. He’s dri­ving down the motor­way. He’s in his BMW. And because in Germany the Autobahn has no speed lim­it, he’s got his foot down, he’s going a fair old clip. And the police pull him over. And they say to him, ​“Hello, Mr. Heisenberg. Do you know how fast you were going?”

And he says, ​“No, offi­cer. But I know exact­ly where I was.”

And the police­man says, ​“We just clocked you doing 120mph, mate.”

And Heisenberg says, ​“Great, now I’m lost!”

Okay, so the peo­ple who are laugh­ing know what the Uncertainty Principle. Heisenberg basi­cal­ly observe that in sub­atom­ic physics, you can­not mea­sure the posi­tion of a par­ti­cle with­out affect­ing its veloc­i­ty. So the more accu­rate­ly you know the posi­tion, the less accu­rate­ly you know how fast it’s mov­ing. And the more accu­rate­ly you can mea­sure how fast it’s mov­ing, the less accu­rate­ly you know where it is. To mea­sure more accu­rate veloc­i­ty you mea­sure over a longer dis­tance, which means you have more uncer­tain­ty around where the par­ti­cle is dur­ing the mea­sure­ment. To mea­sure its posi­tion, the only way to do that is to bounce some­thing off it. Imagine you’ve got a soc­cer ball and a dark hall, and you’re try­ing to find out where it is by throw­ing golf balls. And soon­er or lat­er one of them is going to go ​“ping!” and come back at you. But as you do that, the soc­cer ball is going to start rolling because some­one just threw a golf ball at it. 

In soft­ware, we try and mea­sure things all the time. Because it’s very very dif­fi­cult in a lot of orga­ni­za­tions and in a lot of pro­gram­ming method­olo­gies and things to tell how good your progress is, to tell how well you are doing. Are you going to hit your dead­line or not? And by try­ing to mea­sure things about the way our sys­tems work, you can actu­al­ly inter­fere with them to the extent they stop working.

A com­plete­ly degen­er­ate exam­ple of this, some­one comes in and goes, ​“Look, this whole fixed salary thing is non­sense. We’re gonna pay you all per line of code. Software is code, and we need code because we need to fin­ish it. So from now on at the end of every day tell us how many lines of code you have writ­ten, and we will pay you one dol­lar for every line of code.” How many peo­ple in here would be mil­lion­aires by the end of the morn­ing? Because when they start mea­sur­ing lines of code, you stop going, ​“No, I’m not doing unit tests any­more. I’m just gonna put new­lines in.” And then, ​“Okay, I’m going to put emp­ty statements.” 

And there’s all sorts of mea­sur­ing things. It’s a quite com­mon in agile. One of the rea­sons why I agile teams and scrum says you should esti­mate every­thing in points is because peo­ple used to esti­mate in hours. And then peo­ple would use the hours as a yard­stick to mea­sure them against. ​“You said this tick­et would take four hours. Why isn’t it fin­ished? You start­ed at 1:00 and I’ve checked in with you 2:00 and 3:00 and 4:00 and 5:00, and it’s still not done.” And you’re like, ​“Well, no four hours was a sort of… Out of all the tick­ets we do in a year and divide them by the num­ber of tick­ets you’ll prob­a­bly got some aver­ages out, but these are not absolute accu­rate metrics.” 

And there’s all kinds of ways of mea­sur­ing things. Anyone ever build web­sites and then go and run them through the W3C XHTML val­ida­tor so you get that green tick that says well done, good job? Your cus­tomers don’t care if your HTML val­i­dates. The only per­son who cares about that is you. And there’s noth­ing wrong with the sort of of crafts­man­ship in pro­fes­sion­al pride. But nev­er once have I had some­one who’s like, ​“Yeah, new prod­uct is ready. Customers want to buy it. But we’re not ship­ping it because the HTML does­n’t val­i­date yet.” It’s like, it does­n’t mat­ter. That’s not the thing you should be measuring. 

Look at why you’re there. What was the the force that got you mov­ing in the first place? How do you mea­sure that? If you’re try to be Uber, how many dri­vers, how many rides, how much rev­enue? If you’re try­ing to be Spotify, how many bands, how many albums, how many streams? What is it you are try­ing to do? Because if you try and mea­sure some­thing else, you are going to end up affect­ing the team and the sys­tem that is try­ing to deliv­er some­thing. Because they’re going to start deliv­er­ing the thing that’s being mea­sured. Because that’s what they’re being assessed on. That’s where the sense of val­ue is com­ing from.

So there you go. That’s kind of the deep the­o­ret­i­cal physics stuff. It’s going to get a lit­tle bit sil­ly now. Murphy’s Law. Murphy was, apoc­ryphal­ly, an engi­neer work­ing in the United States Air Force in the 1960s. They were doing exper­i­ments with the decel­er­a­tion on the rock­et sleds. So they’d get a crash test dum­my and they would put it in a chair on a sledge on a rail­way. And they would put a rock­et on the back of it and they’d smack it into a wall as hard as they could. And then they were like, ​“Damn, we did­n’t actu­al­ly get any read­ings 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 after­wards how much strain each of the con­tact points on the har­ness had been sub­ject­ed to. And John Stapp I believe was his name, was the Air Force colonel con­duct­ing the exper­i­ment. And Murphy was the guy who installed the strain meters. And the strain meters were sym­met­ri­cal. They were phys­i­cal­ly sym­met­ri­cal, but they only worked one way round. And he installed every sin­gle one of them back­wards. And the phrase Murphy’s Law was immor­tal­ized in a paper that Stapp wrote after­wards where, depend­ing which ver­sion of this you read and where the prove­nance comes from, is either ​“If some­thing can fail, it will fail” or ​“If there’s a way of get­ting it wrong that bug­ger will do it.” 

Murphy’s Law is inter­est­ing because Murphy’s Law is some­thing that you want to keep in your head when you’re think­ing about user expe­ri­ence inter­ac­tion and the way that you design and build your sys­tems. So, one of the sort of great exam­ples of this is the old joke, when the inven­tor of USB dies, they’re going to low­er his cof­fin into the hole, stop, pick it up, turn over, and low­er it in again.

USB is… So for starters, you get sys­tems where you can actu­al­ly destroy some­thing. One of the inter­est­ing dis­tinc­tions between the United Kingdom, where I’m from, and most of Europe is that you can’t put our mains plugs in upside down. With alter­nat­ing cur­rent, it does­n’t real­ly mat­ter because live/neutral, neutral/life. There aren’t very many con­sumer devices that are sen­si­tive to that. But I always find it a bit inter­est­ing you know, I have an exten­sion cord where I put a European plug on a UK four-way brick so I can plug lap­tops and things in. I had to go and buy a Norwegian plug for it. And I open the thing up, I’m like which way round do you wire this? And it’s that actu­al­ly it does­n’t matter.

But if it did mat­ter, then every time you plugged in a ket­tle or a lap­top or any­thing in Europe you have a 50/50 chance of blow­ing it up. Because if the plug fits the wrong way round and it should­n’t… Now, USB looks like it’ll fit the wrong way round, but then you real­ize as you get in and there’s actu­al­ly a thing inside it that stops you insert­ing it backwards.

Nine-volt bat­ter­ies, the PP3 bat­ter­ies, the rec­tan­gu­lar ones. You know they’ve got a lit­tle crown and they’ve got a lit­tle knob­ble on the top so that you can’t con­nect them the wrong way round? It’s exact­ly that. If it mat­ters which way round some­thing is going to be done, make it impos­si­ble to get it wrong. Don’t build a strain gauge that looks exact­ly the same until you crash it into a wall with a crash test dum­my on it.

The Apple Lightning con­nec­tor, the one they use on the new iPhones I think is a bril­liant exam­ple of this, because it works both ways. It’s like a European plug. It’s a USB con­nec­tor but it does­n’t mat­ter if it’s this way up or that way up, so you can’t get it wrong. So you nev­er again have that thing of of scrab­bling and going, ​“Oh, it won’t fit,” and hav­ing to turn it over and doing it the oth­er way like you do with Micro-USB.

The oth­er thing where Murphy’s Law is inter­est­ing is think­ing about the inter­ac­tions between your users and your sys­tems. Because if some­body is going to— You’re build­ing an input, say, on a form and you’re test­ing it, some­body out there is going to do the wrong thing. Somebody is going to do it. 

The joke I love about this is a bad soft­ware tester walks into a bar. They order a beer, two beers, glass of wine, gin and ton­ic, pack­et of peanuts… Check. It’s good to go. The bars is ready. A good soft­ware tester walks into a bar. They one beer, two beers, a glass of wine, ‑1 beers, a mil­lion beers, infin­i­ty beers, a lizard. Because they’re test­ing the edge cas­es. Because it is all too com­mon for us as devel­op­ers, because we have devel­oped these men­tal mod­els of the inter­ac­tion mod­els of the sys­tems were build­ing, you have a pic­ture in your head of what your user is like. And some­times when you meet a real one it can be a real shock. Because they are noth­ing, at all, like the per­son you imag­ines was going to be using your system.

So when you are test­ing, when you are devel­op­ing sys­tems and putting things togeth­er, don’t always think ​“how can we make this right?” Concentrate on the gold­en path by all means. If your users are smart, they’re pay­ing atten­tion, they’re doing the right thing, make that as seam­less and pain­less and pleas­ant as pos­si­ble. Because user expe­ri­ence is so fun­da­men­tal to delight­ing users. But also think about what can go wrong. Because Murphy’s Law says if some­thing can go wrong, it will, even­tu­al­ly. There is a corol­lary that says it’ll also go wrong at the worst pos­si­ble time. 

Okay, so ten laws of soft­ware devel­op­ment. We’ve had Newton one, two, three. We’ve had the equiv­a­len­cy prin­ci­ple. We’ve had the uncer­tain­ty prin­ci­ple. We’ve had Murphy’s Law.

Zipf’s Law. Zipf was a lin­guist, and Zipf dis­cov­ered some­thing which is true, and is freaky as hell, and no one knows why it is the case. Zips was ana­lyz­ing the fre­quen­cy of words in nat­ur­al language—spoken lan­guage, and writ­ten lan­guage. The most com­mon word in English is ​“the.” The sec­ond most com­mon word in English is ​“of.” Which in any rea­son­able cor­pus of writ­ten English occurs about half as much. The third most com­mon word is ​“and.” It occurs approx­i­mate­ly one-third as much. The 5,570^th most com­mon word in English is ​“source,” and it took us almost exact­ly ¹⁄₅,570^th as often as the word ​“the.” There is this remark­able pow­er law dis­tri­b­u­tion of nat­ur­al lan­guage, and no one under­stands why this is the case. 

And when you start look­ing for it, you find that the same pow­er law dis­tri­b­u­tion starts crop­ping up in all kinds of places. If you look at the pop­u­la­tions of large cities, the United States is a good exam­ple of this. The sec­ond most pop­u­lous city has about half as many peo­ple as the first. The third most pop­u­lous has about a third as many peo­ple. And this dis­tri­b­u­tion fol­lows all the way down. 

And there is one the­o­ry that this it’s a prod­uct of the fact that we are human beings and we’ve subconsciously…as a soci­ety, as a group, we tai­lor and we opti­mize the things we have to wor­ry about to keep them at a man­age­able scale. We want some­thing which is infre­quent. Naturally, we are wary of using it more often because it is infre­quent. So it seems alien. The word ​“the” is very famil­iar. People use it read­i­ly because they’re com­fort­able with it because they see it all the time. It’s always there. It’s omnipresent. A word like ​“source” you need a more spe­cial­ist appli­ca­tion for. 

And this ⁸⁰⁄₂₀ rule crops up all over the place. It occurs in code­bas­es. If you look at the num­ber of func­tion calls and func­tion rou­tines and cyclo­mat­ic com­plex­i­ty of your code, then you’ll find a sim­i­lar pow­er law dis­tri­b­u­tion. You have some­thing at the top, you’ll have some­thing that’s used about half as much, about a third as much. 

And this is very close­ly aligned to some­thing called the Pareto Principle, which is also known as the ⁸⁰⁄₂₀ rule. Which also applies in all sorts of sit­u­a­tions. Basically, 80% of your users will only ever use 20% of your fea­tures. 80% of the—have you ever had the expe­ri­ence where you come in to work on a Monday or you sit down to work at home on a Monday, and by the end of the day you’ve pret­ty much fin­ished some­thing? And then it takes you the whole rest of the week just to get the cou­ple of bugs out and get it ren­der­ing in this one brows­er and work out why that unit test is fail­ing? 20%, lit­er­al­ly one day out of five—Monday Tuesday Wednesday Thursday Friday—Monday is the 20% of the time where you get 80% of the fea­ture set done and deliv­ered. And then it takes you the rest of the week to do all the lit­tle snag­ging edge cas­es that real­ly aren’t that impor­tant, but if you’re going to ship the thing they’ve got to be right. Eighty per­cent of the bugs and defect reports in your soft­ware will come from 20% of the lines of code. I’m not going to go as far as say­ing that on teams 80% of the work is done by 20% of the peo­ple, but I’m sure some of you are think­ing, ​“Hang on…” 

And yeah, Zipf’s Law, it’s true. It holds true for all sorts of data sets and things. It’s real­ly inter­est­ing to think about when you’re pri­or­i­tiz­ing and you’re decid­ing the fea­ture set and scale of the sys­tems that you’re going to build. But we don’t know why it’s the case. There’s just some­thing about things cre­at­ed by peo­ple that likes them to fol­low a pow­er law dis­tri­b­u­tion. And I would be fas­ci­nat­ed if one day they actu­al­ly find out why.

So, sev­en laws. We’re going to move on to the last three. The last three are where we start real­ly talk­ing about laws all of soft­ware as opposed to tak­ing laws of physics and and try­ing to make them fit and stuff. So the last three laws we’re going to talk about are Amdahl’s Law, Conway’s Law, and Moore’s Law.

Amdahl’s Law is about the rate of improve­ment you can achieve in par­al­lel com­pu­ta­tion by adding more resources to it. So a good exam­ple of this, say we’re orga­niz­ing a par­ty. We’re going to have a nice big NDC after­par­ty tonight, and we need to pre­pare for it. And we’ve got…150 peo­ple in this room? Fifty peo­ple in this room, say. So we want to make a lit­tle lit­tle bag with sweets and stick­ers and stuff for every­body, because it’s not a par­ty unless you get a lit­tle 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 work­load. We’ve got fifty— Say it takes ten min­utes to make one of these lit­tle par­ty bags. So we’ve got fifty pieces of work that take ten min­utes each. So that’s 500 min­utes, ten hours give or take. And some­body needs to get a train to Sweden, which will take four hours, and pick up the cake and bring it back; take anoth­er four hours. So if you, sir— I nom­i­nat­ed you and said, ​“You’re gonna have to do all the work because this is your par­ty. You’re gonna have to do it,” how long’s it going to take you? So you’ve got ten hours to make up all the par­ty bags. And then eight hours to get to Sweden, bring the cake back. So you’re look­ing at eigh­teen hours, say. Take short days, long lunch­es. Call it three days’ worth of work. 

Get some­one to help you. So you, sir. You’re like, ​“Come on. Let’s help out.” You’re going to make half of the par­ty bags here. So, you’ve got to make twenty-five, you’ve got to make twenty-five. So, sud­den­ly, you’ve reduce the work­load involved. You can do a day and you can do a day. You’ve got all the bags made made and then some­one has to go and pick up the cake. So some­one says, ​“Well this is good. Why don’t we get some­one else to go and pick up the cake while we make par­ty bags.” So we’ll get you to help out. 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, every­one here all decide they’re all going to pitch in and make par­ty bags. How long’s it going to take? One day. There is no way adding more peo­ple can achieve that in less than a day, because we have a piece of time­bound work that can­not be par­al­lelized. There is no way that some­one can bring the cake back while some­one is on the train to Sweden to pick it up. What it does is it impos­es an upper lim­its on the num­ber of effec­tive cores, threads, process­es, that will give you any improve­ment in how a piece of work is being done.

So, Moore’s Law, the oth­er one we’re talk­ing about here. Gordon Moore worked for Intel, I’m sure you’re all famil­iar with Moore’s Law. Basically it said that com­put­ers got twice as fast for the same mon­ey every eigh­teen months. Originally, his obser­va­tion was—this was back in the ear­ly 1980s, I think? And he observed that the num­ber of tran­sis­tors you could fit on the same piece of sil­i­con was dou­bling every eigh­teen months. And he thought this would prob­a­bly be true for about anoth­er two or three years. 

It has proved to be true for two or three decades. It was absolute­ly spot-on. And because so much sys­tems design and inter­ac­tion and sys­tem capa­bil­i­ty scales direct­ly with the amount of pro­cess­ing pow­er, which is the num­ber of tran­sis­tors you can fit on a sil­i­con wafer, basi­cal­ly com­put­ers got twice as fast every eigh­teen months. For the same price. So on the one hand we have sys­tems becom­ing more more pow­er­ful in terms of the amount of par­al­lelism they can do. On the oth­er hand, we have Amdahl’s Law, which impos­es lim­its on how much of an improve­ment you can get by adding more process to it.

Now, what’s inter­est­ing with Amdahl’s Law is think about in terms of peo­ple. So, go back to our exam­ple. There we’ve got a project that we can­not par­al­lelize. There is no way we can orga­nize a par­ty— You know, it’s half past three now. The con­fer­ence fin­ish­es at half past six. There’s no way we can have our par­ty ready in three hours no mat­ter how many peo­ple we hire to help us orga­nize it.

If you are work­ing on a soft­ware team and you have activ­i­ties which can­not be par­al­lelized and a time­bound, they impose an upper lim­it on how much faster you can go by adding more peo­ple to it. The clas­sic exam­ple of this is meet­ings. If you have eight hours worth of meet­ings that are nec­es­sary because that’s how you’re project works, there is no way you can hire enough peo­ple to do that project in less than eight hours. And so it impos­es an upper lim­it on— Take the total amount of time. You’ve got twen­ty days’ work to do? Except two days of them are meet­ings. You can get ten peo­ple on that team, but the eleventh per­son will have noth­ing to do. Because the meet­ings are hap­pen­ing and every­one else is already busy, and that’s it. All of the work is being tak­en care of. All your tick­ets are in flight. Everything is already happening.

So these pat­terns of lock­ing com­po­nents. If you think about dis­trib­uted sys­tem design. So, imag­ine for one sec­ond that we had an online com­merce web site. Customer’s going to con­nect to our web site. They are going to place an order. We’re going to talk to the inven­to­ry sys­tem. Determine that we’ve got that par­tic­u­lar type of…I don’t know, NDC par­ty 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 inven­to­ry, do we have the cake, yes. Respond. Check with the account sys­tem, is this cus­tomer val­i­dat­ed? Yes. Okay. Send a mes­sage to the ware­house sys­tem, please ship this cake to this address. Yes. And then send a response back. 

And those sys­tems may take three, four, five sec­onds to recov­er. But what we’re going to do, when­ev­er any­one hits our web­site we are going to set up a mas­sive dis­trib­uted trans­ac­tion and take an atom­ic lock on every sin­gle com­po­nent in the entire sys­tem, until all of them, they are not allowed to deal with any oth­er requests or process any oth­er work. So whilst we’re order­ing the cake, the web­site is effec­tive­ly down for every­one else in the world. The ware­house sys­tem is down for every­one else in the world. The stock con­trol sys­tem is down. The deliv­ery sys­tem is down. When you look at like that it seems absolute­ly crazy, does­n’t it. No one would ever build soft­ware like that.

But you’ll call half a dozen peo­ple into a room and sit them down to have a meet­ing and say, ​“None of you can do any­thing else for the next two hours.” We are get­ting very very good at mod­el­ing dis­trib­uted sys­tems in terms of autonomous actors that have their own work­loads, they have their own inputs, they have their own out­puts, and they can deal with the work that comes to them as effec­tive­ly as pos­si­ble, and these sys­tems are easy to scale up.

And this brings us on to the tenth of the laws we’re talk­ing about today, which is Conway’s Law. Mel Conway observed in 1964 that orga­ni­za­tions that cre­ate sys­tems will tend to cre­ate sys­tems that reflect the com­mu­ni­ca­tion struc­tures of the orga­ni­za­tions that built them. This is some­thing that I’ve done a lot of think­ing, a lot of research, and a lot of speak­ing about. Peter Hintjens sum­ma­rized this as ​“if you have shit peo­ple you’ll have shit code.” Which is a fair­ly piffy kind of syn­op­sis of how it works.

What it means is if you’ve got two teams who for what­ev­er rea­son com­mu­ni­cate amongst them­selves bet­ter than they com­mu­ni­cate with the oth­er team, you’re going to end up with two very tightly-coupled com­po­nents with some kind of inter­face lay­er between them that does­n’t work quite so well. If you’ve three, four, five teams, you’re going to end up with three, four, five dif­fer­ent com­po­nents. If you’ve got teams that talk to each oth­er very read­i­ly, then the inter­face between those two teams is going to be good. It’s going to be fit for pur­pose because those peo­ple will com­mu­ni­cate. If you’ve got two teams who are very bad at main­tain­ing the bound­ary, you are going to get tight cou­pling, because two com­po­nents that were sup­posed to be sep­a­rate end up being bound together.

So we have these three laws. We have Moore’s Law, which says that sys­tems are get­ting cheap­er. Computation is get­ting cheap­er, every­thing’s get­ting more expen­sive. And you know, when I first start­ed doing soft­ware devel­op­ment, I prob­a­bly spent about an hour a day wait­ing for my PC to do things. Now I prob­a­bly spend about an hour a day wait­ing for my PC to do things. Because we’re not using all of this amaz­ing com­put­ing pow­er to do the same things quick­er. We’re using it to do more things. And so the fact that the amount of time you spend inter­act­ing with the sys­tem remained con­stant must mean that the com­plex­i­ty of the sys­tems we are build­ing is dou­bling. There is a love­ly quote, ​“the great­est achieve­ment of the soft­ware engi­neer­ing indus­try is to com­plete­ly neu­tral­ize the aston­ish­ing advances made by the hard­ware engi­neer­ing indus­try.” So the sys­tem’s are get­ting twice as pow­er­ful, but they’re not get­ting twice as fast at actu­al­ly doing real stuff, which means that the work they’re doing is get­ting twice as com­pli­cat­ed. Which means we are build­ing more and more and more com­pli­cat­ed sys­tems, and the com­plex­i­ty of those sys­tems is dou­bling every few years.

Conway’s Law says that the sys­tems will reflect the com­mu­ni­ca­tion struc­tures of the orga­ni­za­tions that cre­at­ed them. And Amdahl’s Law says that you have this upper lim­it on how effec­tive your team sizes can be if you have things like meet­ings and work that can­not be scaled and bro­ken down.

So effec­tive­ly, the mes­sage we can take, the way that we can syn­the­size all of these laws into rec­om­men­da­tions and things we can think about and how we do approach the task of build­ing soft­ware dif­fer­ent­ly… We’ve got to get bet­ter at com­mu­ni­cat­ing asyn­chro­nous­ly. We’ve got to get bet­ter at inter­act­ing with teams and orga­ni­za­tions. The open source mod­el kin­da got this right, almost from the word go. How many peo­ple ever went to a meet­ing for an open source project they work on? Let alone a meet­ing at nine o’clock in the morn­ing where cof­fee and donuts are served.

They got this dis­trib­uted, asyn­chro­nous, peo­ple do work when they’re ready, we main­tain infor­ma­tion and sta­tis­tics and peo­ple can work on it in their own time. That mod­el is going to become more more wide­spread. Because in order to con­tin­ue keep­ing pace with the devel­op­ment of the sys­tems we’re build­ing, we need big­ger teams. And there is a lim­it on how big teams get if you are doing things like hav­ing meet­ings. So, get rid of all the meet­ings. Make a mas­sive dis­trib­uted team that’s basi­cal­ly every­body in the world. And love the fact that every­thing you do is going to be run­ning twice as fast in two years’ time but it won’t mat­ter because you’re going be doing twice as much with it.

And I think we’re gonna stop it there. Thank you.

Are there any ques­tions? I love it when there’s no ques­tions. It means you have all achieved com­plete enlight­en­ment. So yes, thank you all very much for com­ing. Enjoy the last bit of the conference.