Seeking Simplicity
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 133 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/48859 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareentwicklerTaskVollständiger VerbandGüte der AnpassungZahlenbereichMultiplikationsoperatorElektronische PublikationBetriebsmittelverwaltungWeb SiteDatenstrukturp-BlockMaschinencodeIntegralSystemaufrufProgrammierungQuick-SortHyperbelverfahrenBitNatürliche ZahlProjektive EbeneCodeARM <Computerarchitektur>PunktMobiles InternetService providerMakrobefehlObjektorientierte ProgrammierspracheKeller <Informatik>Komplex <Algebra>LeckSoftwaretestSoftwareAggregatzustandKlasse <Mathematik>Office-PaketHalbleiterspeicherSpeicherverwaltungAbstraktionsebeneDigitale PhotographieProzess <Informatik>GraphfärbungGebäude <Mathematik>MaßerweiterungWort <Informatik>BAYESFrequenzDienst <Informatik>sinc-FunktionIndexberechnungReelle ZahlInhalt <Mathematik>Spezielle unitäre GruppeMereologieQuellcodeDatenverwaltungRechter WinkelDifferenteComputeranimation
07:23
SoftwareentwicklerPunktBenutzerschnittstellenverwaltungssystemProgrammiergerätQuick-SortCodeDickeKlasse <Mathematik>AbstraktionsebeneDivergente ReiheVollständiger VerbandMehrrechnersystemSystemaufrufProgrammierungBesprechung/Interview
08:30
SoftwareentwicklerMultiplikationsoperatorWort <Informatik>CodeBitGüte der AnpassungBesprechung/InterviewProgramm/Quellcode
09:21
WiderspruchsfreiheitSoftwareentwicklerKomponente <Software>SoftwareComputerarchitekturKategorie <Mathematik>Physikalisches SystemMAPCodeObjektorientierte ProgrammierspracheWiderspruchsfreiheitZusammenhängender GraphBenutzeroberfläche
10:24
SoftwareentwicklerPunktLesen <Datenverarbeitung>WinkelFlächentheorieBitQuick-SortLesezeichen <Internet>Motion CapturingSoftwareDigitale PhotographieSichtenkonzeptVerschlingungElektronische PublikationWeb logComputerunterstützte ÜbersetzungComputeranimation
12:11
SoftwareentwicklerVolumenvisualisierungMultiplikationsoperatorEreignishorizontComputerunterstützte ÜbersetzungNewton, IsaacPunktVersionsverwaltung
13:28
SoftwareentwicklerBeschreibungskomplexitätSoftwareObjektverfolgungProgrammiergerätInterrupt <Informatik>Normierter RaumCLIPhysikalisches SystemKomplex <Algebra>Komplexes SystemSoftwareKomplex <Algebra>Physikalisches SystemDämpfungMultiplikationsoperatorQuick-SortZahlenbereichPunktInverser LimesTwitter <Softwareplattform>Web-SeiteGüte der AnpassungGarbentheoriePhysikalische TheorieBitGesetz <Physik>SichtenkonzeptSchreib-Lese-KopfInterrupt <Informatik>SelbstbezüglichkeitSchlüsselverwaltungMomentenproblemAlgebraisch abgeschlossener KörperBitrateBesprechung/Interview
17:52
SoftwareentwicklerGeflecht <Mathematik>SimplexverfahrenLateinisches QuadratAlgebraisch abgeschlossener KörperMultiplikationsoperatorDifferenteGarbentheorieRichtungSimplexverfahrenWort <Informatik>Komplex <Algebra>Inverser LimesGruppenoperationZahlenbereichE-MailLastBitZellularer AutomatMusterspracheProgrammierungsinc-FunktionVideokonferenzEinsLateinisches QuadratTermReibungswärmeFreewareKontrast <Statistik>Luenberger-BeobachterFlächeninhaltQuadratzahlInformationsverarbeitungGeflecht <Mathematik>Offene MengeFaltung <Mathematik>ProgrammiergerätVierRechter WinkelQuick-Sort
23:05
SoftwareentwicklerVideokonferenzSpieltheorieCASE <Informatik>Quick-SortGraphfärbungBitSpieltheorieComputeranimation
24:08
SoftwareentwicklerEreignishorizontGeflecht <Mathematik>Lateinisches QuadratMathematikFamilie <Mathematik>Rechter WinkelHalbleiterspeicherInverser LimesSoftwareInformationsverarbeitungKopula <Mathematik>Komplex <Algebra>FlächeninhaltBitWort <Informatik>Arithmetisches MittelZahlenbereichTermFaltung <Mathematik>Umsetzung <Informatik>VersionsverwaltungDiagrammAggregatzustandQuick-SortKartesische KoordinatenCASE <Informatik>Ordnung <Mathematik>GeradeProzess <Informatik>PunktKompakter RaumQuellcodeVorzeichen <Mathematik>ResultanteLateinisches QuadratMomentenproblemDialektComputeranimation
30:46
SoftwareentwicklerTypentheorieMultiplikationsoperatorFunktionale ProgrammierspracheBitKomplex <Algebra>Mechanismus-Design-TheorieÄquivalenzklasseZwei
33:13
SoftwareentwicklerKomplex <Algebra>Funktionale ProgrammiersprachePunktFormation <Mathematik>Verband <Mathematik>Ordnung <Mathematik>Kontrast <Statistik>Automatische HandlungsplanungMultiplikationsoperatorMusterspracheComputeranimation
34:03
SoftwareentwicklerProgrammierspracheKomplex <Algebra>CodeProgrammierungProzess <Informatik>MAPDifferenteFramework <Informatik>ExpertensystemEinfach zusammenhängender RaumDiagrammDienst <Informatik>Formation <Mathematik>GeradeBasis <Mathematik>
36:23
SoftwareentwicklerSchätzfunktionFlächeninhaltRechter WinkelAnalysisChaotisches SystemPhysikalisches SystemSoftwareQuick-SortKategorizitätProjektive EbeneMapping <Computergraphik>Problemorientierte ProgrammierspracheTeilmengeATMMAPOvalEntropie <Informationstheorie>Produkt <Mathematik>Güte der AnpassungPhysikalischer EffektSoundverarbeitungWort <Informatik>Zentrische StreckungDiagrammArithmetisches MittelDifferenteUnordnungTypentheorieKomplex <Algebra>ExpertensystemMomentenproblemDatenfeldBildgebendes VerfahrenEinfach zusammenhängender RaumKontextbezogenes SystemLastSoftwaretestCASE <Informatik>Immersion <Topologie>Endliche ModelltheorieBitMultiplikationsoperatorMailing-ListeDatenstrukturPunktEreignishorizontMusterspracheSystemaufrufNotepad-ComputerStrömungsrichtungData MiningUltraviolett-PhotoelektronenspektroskopieComputeranimation
42:21
RechenwerkCodeGerichtete MengeBefehlsprozessorPhysikalische TheorieAbstraktionsebeneGewöhnliche DifferentialgleichungVorzeichen <Mathematik>Bloch-FunktionSoftwareentwicklerEndliche ModelltheorieMAPQuantenmechanikAbstraktionsebeneMinimalgradAssoziativgesetzKomplex <Algebra>Leistung <Physik>Endliche ModelltheorieMaßerweiterungTwitter <Softwareplattform>BitEinsKraftSchlüsselverwaltungZentrische StreckungBasis <Mathematik>LeckComputeranimation
44:25
SoftwareentwicklerNP-hartes ProblemAbstandAbstraktionsebeneQuadratzahlWurzel <Mathematik>EinsZahlenbereichDivisionLeckProjektive EbeneMultiplikationsoperatorAdditionNegative ZahlVerzweigendes ProgrammTermNichtlinearer OperatorImaginäre ZahlMathematikSoftwareBitKomplex <Algebra>Differenz <Mathematik>FlächeninhaltMultiplikationZentrische StreckungInversePunktWeb-SeiteGrenzschichtablösungBruchrechnungImplementierungKraftRechenschieberDatenstrukturBildschirmmaskeComputeranimation
48:41
MathematikRationale ZahlInklusion <Mathematik>Objektorientierte ProgrammierspracheZahlenbereichKomplex <Algebra>SoftwareentwicklerOISCStatechartProgrammierspracheAbstraktionsebeneExogene VariableQuick-SortBitDienst <Informatik>MAPInterface <Schaltung>RichtungMultiplikationsoperatorProgrammierungKartesische KoordinatenTermFormation <Mathematik>Kontextbezogenes SystemZentrische StreckungZahlenbereichCASE <Informatik>SubstitutionFunktionale ProgrammierspracheStellenringRippen <Informatik>Physikalisches SystemSystemaufrufDigitale PhotographieCodeRationale ZahlNegative ZahlInterpretiererBefehl <Informatik>AbstandVideokonferenzProgrammbibliothekFramework <Informatik>Objektorientierte ProgrammierspracheReelle ZahlFlächeninhaltKomplexe EbeneMereologieSoftwareentwicklerPunktFlächentheorieStützpunkt <Mathematik>RechenschieberHöhere ProgrammierspracheKomplex <Algebra>KraftEinfache GenauigkeitComputerspielVerschlingungIntegralDatenstrukturDifferenteEnergiedichteGrenzschichtablösungTeilbarkeitKategorie <Mathematik>SprachsyntheseKomplexes SystemAggregatzustandVollständigkeitVorzeichen <Mathematik>
55:40
SoftwareentwicklerBeschreibungskomplexitätWeb logCodeZeichenketteAggregatzustandProgrammierspracheHöhere ProgrammierspracheMultiplikationsoperatorKomplex <Algebra>ProgrammbibliothekGüte der Anpassungp-BlockPoisson-KlammerAbstraktionsebeneFunktionale ProgrammierspracheÄhnlichkeitsgeometrieRechter WinkelDatenflussRechenschieberTwitter <Softwareplattform>Web SiteParametersystemDateiformatMultiplikationCASE <Informatik>BitMathematikElement <Gruppentheorie>WinkelTransaktionDatentransferGeradeVariableAlgebraisch abgeschlossener KörperExistenzaussageBildschirmmaskeZahlenbereichOrdinalzahlProzess <Informatik>ExpertensystemQuick-SortResultanteHalbleiterspeicherReelle ZahlMereologieThreadDifferenteWort <Informatik>Komplexes SystemSoftwareArithmetischer AusdruckPunktNichtlinearer OperatorRohdatenFamilie <Mathematik>SchlüsselverwaltungComputerspielQuaderLokales MinimumFehlertoleranzKontrast <Statistik>Office-PaketComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:07
Thank you so After this talk there will be a small test The test is to see if you're able to put a green token in the market despite being tempted by various other colors So watch out for that
00:22
Actually before I get started on my way in this morning looking to see where room five was to see where I was going to be speaking and Saw this sign and for a while. I was worried that we're all going to fit in Turns out the two separate things. Oh, we're okay There's actually quite a few people that turn up, so that's just as well. Thanks all for coming
00:43
we're going to be talking about the simplicity and I deliberately chose the wording in this title and seeking the simplicity because I want to emphasize the fact that this is Sort of a process or a journey Rather than just a destination in fact as though come out a bit later. We may not always want to arrive at that destination
01:02
But that the journey is the important part And while we're talking about journeys, it's a good excuse for me to tell a little story because Thinking back through my own career my own journey in search of simplicity number of stories that I could tell to use as examples of
01:22
the merits of simplicity the problems with complexity I picked this one Mostly because there's some interesting features a little bit of a twist at the end But I'm sure we've all got plenty of stories that we can think of To illustrate the points as well so in this story there are four companies hence the the name here
01:44
All interrelated in some way going to introduce them to you now first one Was a company based in Silicon Valley this happened to be the company that I was working for at the time I've left out all the names of the companies mostly just to make it a little bit more mysterious
02:03
The company I worked for was the one at the back there just by the bay It's certainly just at the front these are the buildings of the the dreamworks animation studios, so that's quite cool But I was over the back And while I was there I was working as an integration engineer and
02:22
This company was at the time before the time of the iPhone Probably the leading provider of the software stacks for mobile devices particularly messaging and browsing And so I'll go on site with customers for periods of like six months at a time
02:40
to help them integrate our software stack in with theirs and I was on site with one particular customer a Paris this time Being there before wasn't anything particularly unusual about this particular project except that There was another company
03:02
involved very well known mobile comms company based in London, Sweden May know who that is And they had a like a separate arm but that had a Another software stack sort of a harbor abstraction layer that they've been selling to to other providers and
03:24
the consequence of this Was it to some extent this integration work with our software stack have become a bit commoditized What do you do when you call the tires the implementing of software? You know it's all see of course So that's where the fourth company comes in an outsourcing company based in Bangalore in India
03:44
So there was me in the middle of these these four companies working on all four of these sites and the project was Was going along At some point maybe a little bit later than it should have been a problem
04:01
arose the problem was that The the startup of this device was was very slow very laggy Seems to be leaking memory and often crashed Take a whole device down with it, which is not a very good state of affairs So late in the project so after a few meetings. It was decided that I would look into what the
04:24
Problem was which I did And the problem seemed to be that the the outsourced engineer who had had written this code Clearly didn't understand the API that the the Swedish company was providing I don't really understand our API's either, and they were writing the code in between so there's no wonder they got it all wrong
04:46
After looking a bit more my conclusion was we couldn't really salvage this code. It's had to be rewritten So a few more meetings later, and it was decided. I would actually do the rewrite and I was quite pleased about this at the time because Because of the nature of my role. I hadn't really done much coding for a couple of years at this point, so
05:05
Quite keen to get down cracked my programming knuckles and Get into some real code so I poured over the API docs for the Swedish API And what was interesting about it was it was a the C API, but it was object-oriented C
05:23
If you've ever heard of object-oriented C before It's it's not a very nice thing achieved by horrendous use of macros and various other things you don't want to know about Made it all seem very complicated So what I decided to do was to extract that API away behind some nicely idiomatic C++ classes
05:46
Because our API was all C++ so I did that and Because I was using native C++ idioms I had better resource management, which got rid of those leaks
06:02
The other problem was the the performance Which turn out to be allocating on the heap for file handles and on a mobile device this was quite an expensive thing so What I came up with is some sort of chunked allocator Structure where the first block is always allocated so most file allocation most file handles
06:23
didn't revolve any allocations at all and that seemed to make the Performances should go away So I was quite pleased with this all seemed to be working quite nicely Hadn't quite finished the integration work when something came up, and I had to go back to our office in the in the UK
06:40
So I left the the offices in Paris But before I actually left Paris itself I've got a call as far as I can tell this photo may actually have been from that call or something Around that sort of time. This is what it looked like 11 years ago And there was a problem
07:02
The Problem was the the other engineers had Got hold of my code, which I checked in for them to start looking at They've been looking at it. They knew it wasn't complete so that wasn't the problem The problem was that they just couldn't understand it Couldn't follow it at all There's no idea what to do with it
07:24
So I was a bit surprised about this because I'd you know gone to great lengths to try and simplify things keep nicely abstracted It's nice idiomatic C++ class except. I've sort of underestimated that all these other engineers that background was really to see They'd only been doing C++. Just to integrate with our our code base
07:43
They weren't really C++ programmers some idiomatic C++ to confuse them And this was such a problem that it was decided after another series of meetings that COVID need to be rewritten again And I was leaving the country at this point so a colleague stepped in
08:03
Did the rewrite They called directly into the to the Swedish API's remove some of the extra layers and everyone was happy so so I'd underestimated the The C++ experience the other engineers, but there are a few other things going on here, which we're going to come back to
08:23
later through this talk But just to round out this particular story when I got back to UK wouldn't see my boss here played by an actor There's a bit of a likeness actually and yeah, he called me in and he said
08:41
Here's what the problem is and this was stuck with me because I Still don't really fully understand what he meant by this because I think we just have a different definition of the word that he used But He said that my code was too elegant And that surprised me because I thought that was a desirable thing someone we should be striving for something aspirational
09:06
Maybe too costly to always achieve, but if you've got it that that's a good thing isn't it and he didn't seem to think so So I do think that he probably had a slightly different different definition of the word in mind I Probably won't ever know for sure
09:20
But I don't know what Wikipedia says about the concept of elegance. I think it's relevant here So I'll put it up here Says that the essential components of the concept include simplicity so there's our thing straight away and consistency of design Focusing on the essential features of an object
09:42
This is not talking about software specifically at all, this is just the general concept of Elegance, but it really nicely captures what we consider desirable properties of a software system So mention simplicity, but also consistency of design and really this is a talk about design
10:03
Design Can occur at multiple levels we think of the design of our code and the architecture Maybe the user interface, maybe the hardware, but it extends up to even everyday objects everyday things And we think of the phrase the design of everyday things may make us think of this book a
10:26
Lot of you probably heard of this maybe have read it design of everyday things Highly recommend you read this if you haven't done Again, it's not about software. It's literally the design of everyday things, but it really give us a Nice view of how things that need to be designed
10:43
If you have read this book, and it was a while ago You might want to read it again Because the first edition came out in the 80s a few years ago. There was a new edition completely updated all of his examples With with modern examples well worth a reread
11:01
But the main point here is That he continually brings out simplicity There's something that he's striving for that we're striving for in designs that being sort of an end goal But also for that simplicity It can be very difficult to achieve it requires great thinking
11:21
This is topic. We're going to pick up a bit in a while Now if you've been to any of Kevin Henny's talks You know that when he recommends a book he likes to take a photo of the book On some surface somewhere I wanted to do the same thing, but have a bit of a problem I don't tend to read physical books anymore, so what I did I
11:43
Took a photo of my iPad So here it is There will be a link to this actually all of the references with this talk There's so many of them. I've captured them in a Separate file should be on my blog site, and there'll be a link to that at the end So don't have to try and capture all of this
12:04
so On that subject of requiring deep thinking I've got a question for you who invented the cat flap There's a popular myth That the cat flap was invented by Isaac Newton
12:24
a Lot of people have said that that's not true. It was actually invented around the same time by leaving it Actually, that's probably not true either. It is a myth but It's a compelling one This idea that something is simple and mundane and every day is a cat flap
12:44
Required someone the intellect of Isaac Newton to invent it Sort of relate to that No, I first came across this myth When I was reading the the douglas adams book dirk gently's holistic detective agency
13:01
And immediately after telling this story of Isaac Newton inventing the cat flap Dirk says this it's a rare mind indeed that can render the hitherto non-existent blindingly obvious I Think that's a really nice way of capturing This idea that it could take a lot of deep thinking to arrive at something that from that point on
13:23
Just seems really obvious and simple so we have this intuitive notion then The simplicity is a good thing complexity therefore must be a bad thing to be avoided and I'm not going to
13:41
Talk about whether that's true or not for a moment, but I want to just sort of dig a little bit more into our Through a community psyche here When I was preparing this talk the first time I started collecting tweets when anyone mentioned anything about simplicity or complexity And I've got a section of them here
14:02
This one simplicity is hard, but complexity is far more expensive The idea here is that if you sort of find yourself like nodding along thinking yeah that I can relate to that But that's the point of this If you don't actively fight for simplicity in software complexity will win, and it will suck
14:23
And we can relate to that Really like this next one the atrogenic complexity The complexity introduced by the attempt to make things simpler. I'm pretty sure I've encountered that a number of times sure most of us have
14:41
Another one it's not actually a tweet, but I came across it on Twitter the first time around you've probably seen this webcomic If you haven't you're sitting any further than about halfway down you probably won't be able to read it But the idea here being that when you have a complex systems holding your head you're reaching some sort of limit and the number of things you can hold in your head at once and
15:02
Just the smallest interruption would Make you drop the whole thing you've got to restart again Again something we can relate to and that's what makes this this funny But the point here is if it was a simpler system to start with you may not have had that problem so a Few more quotes before we move off this but from before the time of Twitter
15:25
So here we got ghouls law probably seen this one before complex system that works it's invariably found to be evolved from a simple system that worked and John Gall was a systems theorist So not a not really involved in software specifically
15:44
Interesting thing here is just actually only half the quote. This is what we normally read the other half It's also interesting complex system design from scratch never works and cannot be patched up to make it work You have to start over with a working simple system
16:03
That's really interesting Going back further in time May have come across this one for every complex problem. There is an answer that is clear simple and wrong Well, I particularly like about this one if it's
16:22
Actually sort of very meta and self-referential Because this is not quite what he said It is clear and simple, but it's also not what he said. It's wrong. He actually said I've got the quote here There is always an easy solution to every human problem neat plausible and wrong so close
16:41
But but not quite right Okay final quote perhaps most famous one of this lot sometimes referred to as Einstein's razor Everything should be as simple as possible but no simpler Another self-referential one it's not actually what he said at least as far as anyone's been able to prove
17:02
What he did say that this was probably condensed from about half a page long So I find it particularly amusing someone's gone to the trouble of simplifying that down to the simplest possible thing But no simpler the other problem here is a lot of people go the other way They do make it too simple, and they drop the last bit of the quote
17:24
Again self-referential, it's okay. That's enough of quotes for now Hopefully, I've forgiven you this idea that you know everyone collectively have this view that simplicity is good complexity is bad It's not entirely wrong, but not entirely right either
17:42
The thing is do we actually know what simplicity is the question So what is simplicity how many of you have seen this talk? By a rich hickey inventor of closure simple made easy Just just one hand was that okay? Well you need to rectify that
18:06
Seen this talk about four or five times now. I was preparing for this a Large chunk of this talk is actually based on material from this talk, so there is some overlap We also go off in different directions, so it's worth watching that as well
18:21
This whole next section is based on some of the things that rich hickey's come up with And he starts just by defining these words in terms of their etymology This is really insightful so the definition of simple Terms of the origins of the word come from the latin simplex and that literally means
18:43
one fold or One braid you think of something crossing over with something else That's it. That's the definition according to where the word came from and by contrast complex from the latin complexus
19:00
Literally means many folds many braids very clear relationship there Even clear if you put some illustration to it So we have these these strips hanging down crossed over over there Nope, if you just cast your eyes to the top of the strips on this side
19:20
It's very easy trivial in fact to follow a strip from the top to the bottom and know which one which one's which No problem at all a little bit harder on on the right hand side You've got to actually follow it all the way down to see where it comes out And that's only four strips It's actually just a very small number
19:41
Before things start to become too interconnected to it's about to follow at a glance It's opens. It's up to a very interesting area of cognitive limits We will think of ourselves as being pretty smart in this industry But actually smartness doesn't have much to do with it Cognitive limits are pretty universal
20:04
As programmers will like magic numbers One particular magic number seven you may have heard of Probably the most famous cognitive limit sometimes called magic number seven plus or minus two
20:20
And this is an observation by a psychologist George Miller You notice that in a couple of different cognitive limits seem to converge on this figure of around seven In fact later it was revised down to about five plus or minus two We couldn't hold more than about five things in our head before we'd either lose them all
20:43
Like the webcomic earlier, or we'd have to somehow group them together Something called chunking come back to that in a minute. So these are pretty universal cognitive limits that we have and And Since that time we've discovered a load more as well all seem to be connected come back to the same very small number
21:05
Give you another example there's There's another phenomena, which pretty sure you'd all be aware of you may not know it by this name So you learn nothing else from this talk. You'll learn this this cool word
21:23
Subitizing here's what it is So I've got these these four these squares here If I ask you how many squares there are you will immediately tell me there's four you don't have to count them You can just see just by looking at it instantly recognize the fourness of this pattern
21:42
And I arranged them regularly there, but even if we scattered them about a bit You'd have no trouble still just instantly recognizing that as as for all about this one That's Slightly more friction there. Maybe you have to count them or maybe you sort of subconsciously group them into
22:02
two groups of three three groups of two Which is an example of chunking? If I arrange them like this Chunking becomes even more evident. We now recognize that as a pattern and that's that's how we deal with complexity by chunking things
22:22
So that that cognitive limit subitizing limit again. It's very low About four or five for most people six to the stretch. It's another one I Want to play this video to you for a bit of fun? You may have seen something like this before
22:43
Let's make sure the sounds off actually You may see something like this before if so follow along with the instructions, which will be shown at the start We go so how many times the players wearing white past the ball you have to watch very carefully
23:39
So I said some of you may have seen this or something like it before
23:43
In which case you probably did spot the gorilla walking through But is the interesting bit so if you knew about the grill you probably saw it But did you notice the curtain changing color or the player player on black leaving the team?
24:02
The game rather watch again see some people didn't what the gorilla? Definitely there curtain changes color, and there's only two players on the black team left
24:29
Doesn't take much For us to be able to miss important things When you're at your cognitive limit But that's that's why we work every day with our software write it out the limits of our
24:41
Cognitive abilities to keep hold of things in memory at once I have to let this run through to the end for copyright reasons Okay, so we've got nice definitions for these words simple and complex I think we've got a good idea of
25:01
What they mean in terms of the origins of the word? Let's put them up against two other words easy and hard Now what's interesting here, and this is another of the points that are richer key mates Is that we often conflate the concepts are simple and easy even than using them interchangeably
25:23
sometimes starting a Sentence by saying something simple and ending it with easy or vice versa So let's look at the definitions of the VZ then following the same process Easy comes from the old French a's eyes are not quite sure how you pronounce that one
25:43
We know that much after that would not hundred percent certain But it's likely that we get that from the Latin adjacent And if so that's very interesting We also get the English word adjacent from that same same word
26:01
Which means you know to lie next to or close at hand so by that Etymology the word easy literally means something that's close at hand and that makes sense if something is Physically near to you. It's easy to reach If something is near to you in terms of your knowledge, and it's close to your existing knowledge. It's it's easy to learn that thing
26:27
But put that definition up against the definition of simple, and you see they're very different things Almost no relationship there at all They're pretty much all fog and all concerns so the fact that we can flake these things so often is a bit of a problem
26:44
It's not just about being you know correct in our definitions. This can actually cause real problems Particularly when you're communicating with someone that has a different idea of what you mean And I've had lots of conversations where An apparent conflict could be resolved by a better understanding of this
27:04
So we'll come back to that a bit in a moment, but so go back to the simple and complex Illustrated this with with black and white here because it does seem like a very black and white Distinction if you look at those word origins you've got one fold or many folds as a very clear line
27:22
As words evolve though they get more nuanced meaning Nowadays, I think it's fair to say it's a bit more of a gray area These are more relative terms you can say that something is simpler or more complex and so there must be
27:41
Verbs then that operate on these two to move from one state to another and of course we have some so if something is It's simple you can make it complex by Complicating it That fits the meaning of that word is to to join by waving so follows our same same etymology
28:05
There's another word Which has basically the same meaning and this is some perfectly legitimate English word that rich hickey again resurrected complex Why would it be useful to use a different word for this
28:23
Well trouble is though the word complicate has become a sort of a nebulous and vague in its meaning Because compact is not really used anymore. We can we can assign a much more precise meaning to it we can talk about compacting two things together and
28:40
Actually think of the you know literally weaving them together two things that shouldn't belong together now together Complicate doesn't necessarily have that connotation So this is this is the term and say rich kick is resurrected it number of people who've Followed follow this and find out you're very useful, but if you use complicate you can also end up with the with the noun complicated
29:08
which May mean the same thing as complex Some people have chosen to distinguish them In useful ways so You'll often hear it said that complex is the inherent complexity of something whereas complicated is
29:26
Something that's been accidentally or artificially Complicated which makes sense when you consider the the word complicate there that can be a useful Shade of meaning, but it's not universally understood, so if you're going to use those meanings make sure that
29:40
You know you establish up front. That's the meaning you're ascribing to it So we'll see in a little while there are other useful distinctions between these words Might also be tempted to try and arrange these These things into some sort of quadrant diagram Which case what goes down here?
30:01
This is actually leading to something not quite ready to get there yet, so hold on to that one I'll take you to a slightly different arrangement The words that we have looked at so far So we've got simple complex complicated We've got easy and hard. They're now arranged in sort of order of preference, and we can read this sort of like the
30:24
Like we do with the agile manifesto. We've come to Favor the things on the left over the things on the right which is not to say that the things on the right Have no value Come to favor the things on the left, so the things on the right do have some value
30:43
What do we actually mean by that have a little diversion? This is the watch This is the watch as well as is the the apple watch I got it when it launched Around the time of its launch there's a bit of controversy over the the gold edition
31:04
Especially with a particular strap it came to about $17,000 I'm not sure what the English equivalent was but Pretty expensive and a lot of people are in arms. You know who would pay so much for a watch They're clearly not watch people Neither am I by the way. I don't want to watch for years before I got this
31:24
But the launch of the Apple watch took a lot of people interested in in what she type things And one of the stories that came out was about this this particular watch Designed and built by Patek Philippe for a Henry Graves in 1933
31:43
Fact it was designed and built over eight years Eight years to build this one single watch Obviously a mechanical watch Why did it take so long to build and if you thought the Apple watch was expensive
32:02
This watch sold at auction. It's under two years ago now for 24 million dollars a little bit more expensive So where did that value come from? Well said took eight years to build the reason was it was designed at the time
32:21
specifically to be the most complicated watch ever built Believe that stands to this day an interesting thing about mechanical watches Is that anything that's not directly related to telling the time is referred to as a complication? If you think of what how a mechanical watch works that makes sense
32:44
Because you have all this machinery in there. That's complicated enough or complex enough just for You know hours minutes seconds anything else on there is going to effectively exponentially increase the complexity of the mechanics This watch has 24 functions
33:01
the 24 complications So you can imagine how complex it is now. You know why it took eight years to build So it's called the super complication Say 24 functions there they all are quickly read those so
33:20
Point here is that complexity definitely does have its place definitely does have value. It's not an isolated example This is Lego not so expensive. I'm using it here to illustrate the concept of Composability which we're going to come back to later, but right now and already to get there yet
33:43
I'm using it now to contrast with these things If you have children of a certain age, you may be familiar with these all the rage a couple years ago called loom bands Ideas that kids can can weave these things together into some quite intricate patterns and things
34:01
So of course someone took it too far I Made a dress tiny out of loom bands, and they sold this on ebay for 170,000 pounds in fact Slightly more than that because it's seven pounds for shipping as well, so complexity
34:29
definitely pays And in fact you think about it really that is where the value is If something is so simple you don't need to do anything at all or then we wouldn't have jobs
34:41
so You know exactly where that complexity lies is where you know we're getting the value out of it So that distinction we made earlier between accidental complexity and inherent complexity is a really important one We want to minimize the accidental complexity so that
35:00
we can we can solve the Inherent complexity we still need to manage that somehow though So how do we manage complexity? I'm going to look at look at this from a couple of different levels We're very high level. There's a framework. I'm going to introduce
35:21
For thinking about how we manage complexity, and then we actually finally get to some some code talk about programming languages and programming techniques But this framework I was talking about it was a good excuse to do this photoshopping exercise If you don't know the title of the original film the joke's lost to you. I'm afraid
35:46
So this is kenefin How many people here have heard of kenefin? Just two okay. How many people here knew that was how it's pronounced just one one and a half and
36:00
How many people know exactly what it is? The other one, okay, that's interesting That's also good because I'm not an expert in kenefin It's something I've read about and I've dabbled with I know enough to find a useful thinking tool But I'm not going to stand up here and tell you all about kenefin, but I'm going to introduce it on that basis, so
36:23
Going back to that diagram. We started looking at earlier Could now tell you what this this word should be in the context of kenefin It's chaotic. We'll look at a moment what that actually means And this is not a quadrant diagram if you say that kenefin is a quadrant diagram then kenefin people will get very upset
36:48
These are domains you'll often see it drawn more like this in fact. There's five domains here The four ones around on the outside and then this void in the middle called disorder
37:03
Some ways it's not a real domain This is just where you put things that haven't yet been classified into one of the other four domains So let's give you a clue as to how you use this thing. This is all just a way of classifying different types of system or different types of project Into these these four domains, so what are the domains mean?
37:24
So we've got simple down here. We'll start with that in fact more recently People in the kenefin movement have been calling that obvious instead of simple In this case they can be used almost interchangeably. I've kept it simple because of our thing
37:42
And this just means any project It's not specific to software projects by the way, but so any system that is Literally obvious you've done this sort of thing many times before There's no surprises. You don't even really need to do much analysis. You just think right you know here's here's what we need to do
38:03
Let's just do it Probably get some good estimates and things This is the area where it's actually probably quite valid to talk about best practice. I don't particularly like that term, but They use it in kenefin So all that you know all the best practices how you're going to work with things like they tend to work well here Because everything's well understood. It's all well trodden ground, so then you've got the complicated domain
38:28
And this is where we diverge from the meanings that we were talking about earlier complicated domain in kenefin, it's We're talking about cause and effect and in the complicated domain
38:45
Cause and effect are not necessarily immediately obvious, but they can be analyzed so you're an expert in your field Then you can probably do that analysis, but it does take an expert So this is the area that a lot of projects find themselves in you need to do some of this expert analysis
39:04
And you can apply what can I think always good practice? And I don't know enough about connecting and really know what the difference between those two is Presuming the good practice is more of a subset of best practice But it's different
39:21
We Start to already Get an idea of why so many projects Have problems because maybe they're applying best practices to something that's complicated or even complex And those practices don't necessarily apply we need to match the practices. We're using to the domain that we're in So complex then in the kenefin sense
39:44
Again talking about cause and effect You can't actually tell what the cause and effect are until afterwards you can only analyze it in retrospect So this is the domain of immersion practice, so you think of
40:04
you know You're working on a project. That's entirely new to your company You don't really have anyone there with with a necessary experience So you need to make a lot of this stuff after to go along or try and get people in but in chaotic
40:22
Even more interesting. This is where there is no apparent relationship between cause and effect We think of Chaos Theory Basically the same thing you know whether systems the butterfly effect Okay, technically there is some underlying cause and effect, but it's not something you can you'll ever be able to analyze
40:43
Not not the right level of detail in software systems, we're think of things like disruptive startups or You've got a new system in production and Something goes wrong. That's completely unexpected You know it's not something you've anticipated. You just got to drop everything else
41:03
Dive in and fix it you're in firefighting mode That's chaotic So these things come up either at the project level or or a small a smaller scale and a little something called the shallow dive into Chaos We start with a system. That's maybe in the simple domain and
41:21
Just to test something out. You know you push a few levers to take it into Chaos and back and learn something from it I'm going to go too much into that. It's not a talk about connecting. I wanted to introduce it to you So as a thinking tool a way of thinking about the complexity of Different projects different systems, and how that can then inform how you're going to approach them and why certain practices won't work
41:47
We're different levels of complexity This is also maps quite nicely onto various other Sort of categorizations of things For example that the drapers model of skills acquisition. You can sort of map it onto these domains and I
42:04
Can give you some insights as well if you google for? Kneff in do like an image search you'll find a load of these diagrams Come up and some of them have some of these extra layering is on it can be quite useful So I'm going to leave connect in there And I'll start to come down a bit to the next level down and talk about
42:24
abstraction Again if you're passed The middle of the room probably won't be able to read this you may have seen this webcomic if not the gist of it is that You know if you keep having to ask what something means you'll eventually get down to quantum mechanics
42:44
So when I first saw this Associated with tweet that said better get comfortable with abstraction, and I'd say abstraction It's probably the single most powerful design tool that we have for managing complexity
43:02
They're very important But it's a double-edged sword it has one big Achilles heel What is that Joel Spolsky put it best
43:20
All non-trivial abstractions to some degree the leaky now the only problem I have with this so they don't think it goes quite far enough I Would actually skip the grayed-out bits And even say all abstractions are leaky at least all useful ones I'll come back to that in a minute, but I
43:41
Think we'll all agree that that most abstractions are are leaky to some extent which means that The details of the thing you're abstracting will actually leak up to the level Of the abstraction itself you end up having to deal with both levels So we're talking earlier about complexing things we're now complexing the abstraction from the thing that's abstracting it
44:05
More complicated than before you abstracted it so the opposite of which what we wanted to achieve by abstracting in the first place but Another quote probably heard this one all models are wrong some are useful
44:21
same with abstractions they remain useful So if we've got leaky abstractions, and there's theoretically Possibility for a watertight abstraction my claim is there's no such thing But if it's a scale we can we can see we want to be more on that side of the scale
44:42
We could put this now up against some of the other terms. We've introduced so Leaky abstractions are on the complex side And said because they're complex the finger abstracting with the thing That's obstructing it Conversely a watertight abstraction should make things simpler, but here's the problem leaky abstractions are easy
45:11
Watertight abstractions are hard to the point of being impossible, but it gets harder as you move across the page and This is not one of those occasions where you can somehow flip these things
45:24
Least not to my knowledge. We can't make it easy to to make a watertight abstraction The best we can do is try to minimize the distance between these things So it's not too hard It's not too complex
45:41
But it won't be so simple either That's easy to do on a slide, but how do we do that in practice? If we get to that I just want to follow up on my claim that All abstractions leak talk about one of the simplest abstractions that we're all familiar with
46:02
numbers Is our number seven again standing in for all numbers? Numbers are probably the most abstract concept that most people actually deal with We've had them around for a long time and over centuries We've also added various operations that we can form on these numbers
46:21
First one almost certainly was addition No real problems there works out pretty well can add any numbers together but the inverse of that is subtraction and That works pretty well until you come down to Zero or and beyond because we didn't get concept to zero until quite recently or negative numbers
46:45
So for ball that had some undefined areas a bit of a leak in the abstraction which we later plugged Multiplication no real problems there because you can implement that in terms of addition but the inverse
47:01
division What if you divide by zero once you have a zero? another leak in the abstraction One that actually remains not fully plugged to this day And various ways you can deal with it, but it's still a problem, and then there's this one
47:23
square roots Squares are not a problem the implemented in terms of multiplication implemented in terms of addition square roots well As we all know there's a problem when you try to take the square root of a negative number Okay, we solve that
47:41
Just by saying well that equals I and there's a whole branch of very useful mathematics that shoots out of that but the problem is Square roots were invented or discovered depending on how you look at it somewhere between the 18th and 16th century BC
48:02
Imaginary numbers were invented somewhere between the 16th and 18th century AD So For about three and a half thousand years this abstraction was leaking now this is Despite the fact that many of the greatest minds that have ever lived have been rigorously analyzing this problem or ones like it
48:28
Now don't about you But I can't quite give that amount of attention and that amount of time to my software projects So I think we're going to have to accept that abstractions leak at least any useful ones
48:41
Just round out This bit about numbers. I like the Wikipedia Quote puts it really nicely that the notion number has been extended over the centuries to include zero negative numbers rational numbers real numbers complex numbers Extend the real numbers and sometimes additional objects
49:01
which sounds like a bit of a fudge at the end there, but Much more complex than it the first seemed I think So How are we going to? reduce that distance between the the watertight and the easy abstractions we'll start with a simple bit
49:23
This is simple But also something that we don't always do To keep our abstractions as small as possible as narrowly defined and focused. There's a real temptation and I find To develop obstructions around metaphors and try to complete the whole metaphor
49:42
But you end up implementing all these things or defining all these things that aren't really relevant to the problem. You are solving If you keep that surface area small as possible We do see The amount of your abstraction that is going to leak And so very closely related to that keep it simple
50:01
Sounds like a tautology Keep your abstraction simple by keeping them simple. That's not quite what I mean I mean the abstraction itself should be defined in simple terms Now don't try to be too clever with it Small and simple will get you a long way. I Think these are fairly universal principles very easy to understand
50:24
Then it gets more interesting and I think we think you need to split here and this is sort of my thinking on the subject But there are really two directions to go in and you need to think about what it is you're doing So the one hand we have what I call
50:40
Global abstractions Maybe there's a better term for this maybe shared not quite sure. So I think shared applies on the other side as well but these are things like Frameworks and libraries services even programming languages You know things that you want to be able to rely on and things that are shared between code bases
51:03
On this side, I think striving to be as complete in watertight as possible It will still leak but as much as possible. I think it's the right thing to do. It's worth the investment There is a scale here. It's not black and white but This side tends to be worth trying to make them complete but within our applications within our
51:28
Services we have local abstractions things that we use all the time. Maybe just extracting a function. That's an abstraction we can be tempted to try and make those complete as well, but
51:43
In a mental energy, but they're going to leak anyway and when they do leak You want to be able to work around them without any extra resistance If you've ever been working through some code base some code base team hit a problem With with some abstraction layer and it's just been much too much extra effort to to go below that abstraction layer
52:05
Even though you've got all the code there Then you know what I mean So keep those local abstractions shallow embrace the fact they're going to leak Now don't try to make them complete Just try to make them useful for that particular case
52:21
So I think there's a two very different ways of looking at it Depending on where in this in a system or what what the purpose of that system is so That's the general in general terms talking about abstractions Now I'm going to go lower level still
52:41
Talk about programming languages and language features So I've made a statement here that we should favor higher level languages and language features Which sounds you know obvious we often say this, but I'm talking about this thing context of simplicity
53:00
And by higher level languages and Language features, I'm mostly talking about as you'll see Things are associated with functional programming languages We'll dig into that a bit How much time we only got 10 minutes left? Gonna skip over the next few slides. I had some examples in C++
53:22
Don't know if everyone's familiar with C++ anyway, so let's skip through that The point here is that we actually end up refactoring something to use some very functional Approaches skip through that
53:40
We'll get to our next example come back to our Lego and loom bands as we said Standing in for the concepts of composition and complecting that we're going to talk about composition here Who came to kevel in Henny's talk this morning?
54:00
Deconstructing solid principles fair few Or if you've seen it before We've done it a few times If you haven't seen it at all you should definitely watch that it's I Found one video available to put in the references at the end Here's a is a photo of his talk this morning. Here's the solid principles
54:22
Not going to go into what the solid principles are most of you probably know I'm not going to spoil kevelins talk too much, but He does sort of rip these apart a bit I Have a slightly different take on this in that I
54:41
So you can actually talk about each of these principles in terms of composition and complecting For example the single responsibility principle is an obvious one If something has a single responsibility, it's not complecting responsibilities together don't belong together and same sort of thing with the integrate interface segregation principle a
55:02
little bit harder with Liskov substitution I Think that's that's the same thing if The strict interpretation of Liskov substitution is that if you substitute one object for for another The behavior of the system should remain unchanged
55:23
So if you're not doing that again, you're complecting different parts of the program together, which Make things more complicated make things harder to reason about so move on from that Talk about composition you can still build pretty complex systems using composition
55:47
this is a Yeah, continuously variable transmission engine built entirely out of Lego for those quite cool another talk
56:02
She just before lunch anyone go to this one. You might recognize these illustrations over here a Number of the number of the points from this talk. I'm covering here this slide is Taken directly from rich icky's tool that I mentioned earlier
56:21
I'm asserting it here now because That's also my next slide might notice a similarity This was this is a really interesting take Again We all know that mutable state is something that we should try and minimize or avoid particularly shared mutable state
56:44
Rich hickey's angle is that the reason for that is because it complex value and time Now if you contrast immutability with mutability you can see why that's the case if something's immutable Doesn't matter when you ask for its value. It's always gonna be the same But if it's mutable then time is actually
57:03
Now part of that that function depending on when you call it. It'll have a different value you may have heard the expression that the definition of insanity Is doing the same thing again and again and expecting a different result, and that's exactly what we do with mutable state
57:21
It is literally insanity so that bits easy enough to understand but hickey made another claim To sort of like provide a solution to this and this might take a little bit more explaining He says that refs compose value in time first of all we have to understand what he means by ref
57:48
So rich hickey was the creator of the language closure And closure has a language feature called refs Haskell has something very similar implemented in libraries
58:05
Closures refs User language feature called software transactional memory. It's definitely not something I'm going to go into now definitely not an expert of that Other languages can give you something very similar
58:21
Achieve the same sort of end so I'll actually try and explain that rather than what rich hickey really meant Its simplest form this is really An example of taking a reference a mutable reference to an immutable value Good example might be a C-Sharp string
58:43
The string itself is immutable But you can change which string it is So if you change that string Then other callers that previously had got that value don't see your changes until they ask for it again So in the case of a ref
59:02
when you ask the ref what its value is you always get a Complete value as it was at that time, but if you ask for it again, it may be now a new value So it's transactional and it's atomic thread safe There's still mutability there. This is for those cases where you still need mutability
59:23
But it strictly controls it and makes it safe So the word compose means to lie next to each other You just like lying blocks next to each other you think about it that way You can now say well. You know these values are you know discrete in time still the time element there?
59:46
So refs compose value in time Probably haven't explained that very well if you want more on that you can always come and ask me afterwards I'll try and do a better job Okay, I've got time to
01:00:00
I'll do this very quick example from F sharp. This was in the end's talk as well, so I won't do too much with this, but this is the pipeline operator in F sharp, very, very simple. This takes the thing on the right and applies it to the thing on the left, where the thing on the right is a function and the thing on the left is an argument.
01:00:23
This was also my proposal for a new logo for F sharp, which wasn't accepted in the end. There you go. So function applied to an argument, so it's basically the same as saying this, no brackets in F sharp when you call a function. So why would you prefer to use the pipeline operator?
01:00:42
What's it actually achieving here? There's actually even more characters to type. Well, let's use a more complex, concrete example. Take a function F, apply it to the argument A, fine, that's probably how you would write it in F sharp even.
01:01:01
Now take another function, G. What's your intention here? Do you apply G to F producing another function, apply that to A, like this? Or did you mean to apply F to A and then that produces a result that you apply G to? If you took either way, depending on your background, you may favour one or the other.
01:01:24
Of course you can use parentheses to disambiguate, so what's the problem? Well, let's introduce another function, H, and another one, and another one. You can see where this is going. Now, I'm using letters here, but if you were using real function names, this is going to be a hideous amount of nested code, and you say, well, I just wouldn't write that.
01:01:45
That's complex code. It's too complicated. You can't really see what's going on. Well, if you consider the poor argument here, like it's helicoptered into the middle, ricochets around between all these brackets, it ends up popping out the left-hand side.
01:02:00
It's really hard to follow, and if you try to format that over multiple lines, there's just no way to format that gracefully. So we just say, no, that's bad. Just avoid that. Don't do it. That's a real shame, because what we're doing here is composition. We're composing these functions together, but we're throwing it away and saying it's
01:02:23
too complicated. But in F sharp, and other languages that have similar features, you can just rewrite it this way, using the pipeline operator. Ah. Now we can see the flow of data. The argument goes in here, flows into F, into G, and so on, all the way down.
01:02:42
We can visually see the flow of the data popping out of M, and we can trivially format it across multiple lines like this, and you see code like this all the time. It's the bread and butter of F sharp. You might say, well, I still wouldn't use so many functions. Maybe that is a lot, but I certainly see four or five of these at a time very regularly
01:03:03
in F sharp, and it's no problem at all. And it's very composable, and you can spit things out very easily. It's just a big win for simplicity, I think. So let's wrap up, because I think I'm going over time. Ah.
01:03:21
So we want to embrace essential complexity, that's where the value is. Simple is not the same thing as easy. I don't mean the same thing at all, or fog and all. What it does mean is something that's simple has very few interleaving parts. And we should favor high-level languages and features, which give us the ability to
01:03:41
make things simple. Our old friends, composition, complecting, we want to favor composition over complecting, even between value and time, we've now seen how we can do that. And abstractions, global abstractions tend to be complete, local abstractions shallow.
01:04:03
And again, avoid or minimize mutable state. Use something like refs if you can. And that brings me to the end of this material. That's where the references are that I mentioned on my blog site. That's me on Twitter.
01:04:21
I do have one more thing, not really related to this talk, but I'm doing a charity run for the London Marathon this year. So feel free to donate on this just giving site. Sorry, Virgin Money site. But I'll leave all of those up there for you for now.
01:04:43
I don't think we have time for questions from the floor, but you can come up to me afterwards. So thanks very much.