Metaphors We Code By: The Hidden Power of Naming in Software Development

[00:00:00]and now give it up for Kevin Henny and the metaphors we code by thank you very much to thanks good morning how are you doing okay excellent right um so here we are um the middle of the week um one of the things I enjoy about German so much is that there is that sometimes there is nothing left to the imagination and to today's day name is middle of the week um just so you know where you are truly centered and what I want to talk about today is another something that has fascinated me for years and I've kind of danced around trying to understand the notion of metaphors and how they relate to the way that we think the way that we name I'm going to immediately offer you the disclaimer that I am not a psychologist I am not a linguist I'm just somebody who's kind of interested in this stuff um so there is clearly a lot more to to this than I'm going to tell you but it should be fun um now once upon a time I just used to put my Twitter handle up but these days well Twitter we have an ex relationship with a lot of the time um and these days there's been certain fragmentation in the social media space so honestly I just there it is you know just find me okay if you're interested stalk me um my name is um somewhat internet unique um in fact even the first name although half the time it most things will try and correct it for you refuse the correction um and there's an interesting thing that name that combination was formed was coined before there was the concept of an Internet and I'm going to come back to networks a little bit later um in terms of other things um Marco said uh at the weekend elevator ride at the marit hotel starts just like Kandinsky will with an act Kevin Henny for various reasons which I'm not going to go into in this talk my name is associated with failure screens and I have been asked what's it like to have your name be associated with failure Kevin I mean you know there's there there's an interesting thing that long after I'm gone people will say yeah there's this guy Kevin Henny and you know he must have walked around and created a lot of failures he was a software consultant um that's not the cause but uh these are of Interest now looking looking back years let's go back five years this is the opening slide to my talk at Kandinsky in 2018 this is the first content slide so I thought interestingly enough I will actually use exactly the same slide same fonts and everything um I'm going to quote from Mya Layman and I will quote from uh my uh his uh same paper again in a bit later um I think this is a classic paper it's published in 1980 it's a culmination of a lot of his work um in the 1970s um very much as the title says programs life cycles and laws of software Evolution he was very much ahead of the curve on this we'll come back to that but what I want to focus on here is the words I think he enjoyed writing this it's a lot of fun okay I mean I mean this is it any program is a model of a model within a theory of a model of an abstraction of some portion of the world or of some Universe of discourse oh that's just fantastic sitting there in the middle of a very credible paper and I offer you this the next time somebody probably you know in your circle of friends who are not software developers or in your family says so what exactly is it that you do for a living give them this they will not ask you to fix their computer okay they'll they'll kind of back away nodding okay thanks um but one of the key words here is model in fact model is used extensively and it's kind of interesting CU I was thinking as I was thinking back I thought okay so I came to Berlin 5 years ago and I did a talk on meaning and I was just thinking back and I Sly thought model there's a there's a thing I was reminded recently that there was a word that I I coined in a master's degree I did many many years ago where I was talking about object systems and concurrency in fact the actor model and I used this term I thought I'm going to sneak this word in and see if my Master's Degree supervisor notices that I've just invented a word modity because what I wanted to do was communicate the idea that a communicating set of actors communicating set of objects with their own State and messaging protocols not only were they modular not only did they have good modularity but they had good modity and I actually ended up using and offering a more formal definition in a keynote that I did last century um a measure of the correspondence between the components of the problem being modeled and those in its solution so you know feel free to borrow this word because it is directly what we're doing here this week is that notion of Correspondence and Alignment now of course there's no such thing as a perfect model but there is this idea of trying to bring things as with any system into some kind of alignment it's an uneasy one there's probably a little bit of movement but at least attempting that and the Very process of doing so is itself interesting now as a general point I'm very interested um in words and definitions and meanings um I I like dictionaries for example in fact I actually these are the only things I install on new laptops I actually from from uh DVDs and CD ROMs uh the there's only let's see three dictionaries the Oxford English Dictionary the concise and the Marium Webster and these days people don't have Optical drives attached to their computers so my wife can always spot when I've got a new laptop cuz I'm running around the house trying to find the one optical drive that we have somewhere collecting dust just so I can install the dictionaries locally and I also have physical dictionaries I think they're fascinating now the thing about the Oxford English Dictionary is that if you are interested in looking up the meaning of the word this is absolutely terrible it's useless that is not what the OED is for this is a book of atmology and history it doesn't show you usage it shows you history so the first definition is the oldest which if you're absolutely into this that's fantastic if you want to know what they meant in the 16th century by the word you're currently looking up this is great otherwise it's absolutely terrible fortunately this is absolutely where I'm interested so we're going to talk about metaphor and we are offered this idea of metaphor this definition the figure speech in which a name or descriptive term is transferred to some object different from but analogous to that which it is properly applicable and if we look at the actual origin metaphora it's Greek ancient Greek it means literally to transfer that is the whole idea of a metaphor it is the idea if we're going to explain this in terms of this going to help you understand it's a mapping now this is kind of cute it's kind of mathematical sort of but there's something deeper here when people learn about metaphor when they think about metaphor often their mind is cast back to school where they may have studied some poetry or some plays or something like that and that in class they were asked to explore the metaphors and the metaphorical language which is very tough for some people um and I noticed this my my younger son he really struggled to get poetry he's we weren't surprised because he's uh he's on the Spectrum um but the whole idea of metaphor is incredibly challenging if somebody kind of uh brings it out like that and uh but there is another aspect here is that it's not just a thing that belongs in poetry and Flowery language the idea is that metaphor actually is deeply woven within the very way that we think it tells us how we use our prepositions okay and you notice this when you switch from one language to another why in one language something may be at something but in another language it may be by something okay and these are all the little bits and pieces that you're kind of going well hang on why is That's So illogical you say when you learn another language why is that at and not by like it is in my language my first language and it's just like yeah there's no logic to it at all or rather there is and it comes from this so this is there's been a lot more work since um since this book but this is kind of very much a landmark book it was published in 1980 funny enough the same year as that uh Mya lemman paper um George Loff and Mark Johnson and they observed in metaphors we live by metaphor is pervasive in everyday life not just in language but in thought and action they go on to say that in trying to describe metaphor it informs everything about the way that we reason particularly with abstract things they given a number of examples I think I can't remember if it's in the book or in uh something else but there's a a very interesting point we talk about in terms of um we relate something abstract typically in terms of something physical and a lot of the things we relate to physically are ourselves so you might say you know may maybe you're showing somebody pictures of your holiday and you've been on holiday you went to the mountains and you say oh yeah here's a picture of me in front of the mountain okay I have some news for you mountains don't have fronts that's not a thing humans have fronts okay but it's in front of the mountain it's like yeah it doesn't make sense a mountain does not have such symmetry uh or breaking of symmetry but we're quite happy to use phrases like that we use them in relation often to our physical selves and they point out this idea the essence of metaphor is understanding experiencing one kind of thing in terms of another and they offer a number of examples and what we see is that with many of these these will these create a system they create a system of meaning and that's so you know we're going Way Beyond the idea here of just like finding nice names for things or understanding just one thing in terms of Another We're creating a system of meaning with entailments so time is money is a very common one in the West and certainly in English there it informs a number of phrases without even thinking about it I mean how are you going to spend today spend is the language of money okay um is it worth spending my time at this keynote well yeah it is for me because I've been asked to that but you can you can sleep if you want but the point there is that that informs all of the little words it's not just about the idea of time is money in the most obvious sense it's the subtle sense as well we see this idea when talking about other abstract Concepts so time is clearly very abstract um argument is war okay what does that what does that do for us how does that inform our our language she attacked his argument attack is the language of War he was defeated okay it informs that kind of language but we can also have multiple systems arguments as buildings his argument was based on a solid foundation found arguments don't have foundations that's buildings okay but clearly once you've got that you can have the idea of that perhaps his argument was not so was not built on such a solid foundation and it collapsed okay we see oh yeah buildings collapse yeah and uh one that is kind of interesting one again linguistic and cultural happy is up sad is down to the point that people will sometimes how are you feeling upbeat I'm feeling up there's even you know there's the there's the uh feel-good site called Upworthy up is a direction that we have an association with feeling down okay and that's L there is that notion and when we talk about the notion of say words like depressed that is a down thing okay literally that's what the word word means and love is a journey where is this relationship going relationships don't go anywhere they're not a thing that goes but how do we talk about them they're such an abstract idea so we have all of these systems that's great so we've understood that we we think in these terms but let's talk about what happens when we take this to let's let's take this to the computer now there is an interest so this book was published uh 2008 pragmatic thinking and learning by Andy Hunt one of the pragmatic programmers unfortunately in the subtitle this is the funny thing is sometimes we will use terminology in in the in the software world and then try and bring it back to the real world and we end up with refactoring your wetware refactoring is to change something so that it has no observable effect on the outside that's not what this book is about it actually wants to have an effect sometimes people get a little bit excited and use the word refact in to just mean changing stuff that's not what it means yeah it's not just changing stuff um but there's a lot of there's some nice observations in here um many of which parallel some of the stuff I've done myself but Windows is one of my favorite example uh examples what we call windows on the computer screen aren't really windows at all but they give us a language and a model through which we can understand things okay windows that gives us a concept of a view it gives is the language of opening and closing but of course there's not a perfect match I mean I don't know if you've ever tried to resize a window my wife and I have done in two houses it's very expensive and minimizing windows I mean they could have gone the whole they could have gone the whole distance and said yep we're going to draw the curtains on this window and it's just like no no that's that that starts getting Sil so what we do is we understand that a metaphor is is not the thing itself it's not going to be a perfect mapping and it turns out we're also quite happy to mix our metaphors probably more so than we would acknowledge I mean windows are part of the desktop metaphor do you keep windows on your desktop I mean that's kind of weird so I can see a window when I say when I home I can see a window from my desktop it's got great resolution it shows me my garden um sometimes the colors are a bit dim but you know that's just from living in the UK um but we have this idea creates a way of thinking about something but that's very different we don't use for example the language of process what is the language of process or the language of machines the language of machines it's actually now the most common the word with the most meanings in the ox English dictionary Run Okay run is a is the language of engines it's the language of Machinery you run an engine so we don't use the language starting and stopping and running when it comes to a window we talk about opening and closing even though technically if you actually look at what's going on underneath it's obviously the same so we have that and a folder on your hard disk isn't a real folder yeah we have these ideas we have um folders they contain files what can you do with a file you can open it you can close it you can read from it you can write to it but now we've got to the point where so many of these are concrete that you know with my kids it's a case of like showing them this is a real file what the actual yeah this is a real file we we've reached that point where the language takes over but there's another interesting thing here the metaphorical language captures a point in time sometimes there is an implied time stamp so what machine does Andy use he's a Mac User he uses a trash can I'm not a Mac User I'm a Windows user I have a recycle bin now why did Windows choose a recycle bin and not trash can I mean given that I mean those of you who use c will know that Microsoft has no problem just ripping off a whole look and feel of a language so they not they don't just do it to be gratuitously different they do it because of the time because in the 1980s when the trash can metaphor became something with Apple recycling wasn't a thing it's a reflect the mid 1990s recycling we had logos for it in the mid 1980s there were no logos for recycle or concept of recycle bin did not have a meaning it's actually a more accurate metaphor okay so the point is that the ma the Macs are stuck with the 1980s view of how to dispose of things whereas the windows uh view stopped started at a different point it captures a different point in time we see this in terms of other language that we might use like Sprint okay the purpose of Sprint why do we call these damn things Sprints they're iterations we don't do them because they're fast although I have heard of teams saying yep we're switching from iterations to Sprints why they sound faster the whole idea of Sprint is that back in the early 1990s the term iteration implied something much longer it wasn't anchored to that meaning of 3 months but if you said we're doing iterative development to somebody in the early ' 90s you were probably talking about 3 to 6month iterations if you were on a 4-year project you might and you were doing iterative development you might have as many as eight iterations the whole idea of Sprint was something shorter that was the implication and without interruption that was the there was another implication it's in a straight line it's direct these days we've lost that so now people are just exhausted through micromanagement so we have the idea that some of our terminology captures different points in time not just the meaning that we thought it did when you write concurrent programs using threads You're Not sewing no you're just wrapping yourself up in a world of pain a cocoon of angst and fear and bugs but that's a different story it's just a matter for so we've got this idea here we use it everywhere I mean even the word computer you go back far enough a computer was a person in fact there was a interesting crossover point this is in the 1940s that's one of the Colossus machines uh used to break the Len Cipher and here you see two computers with a computer but that was that thing would have been distinguished oh by the way whenever people talk about old computers they was like to joke about how much memory these things have this and like how many bytes this had zero bytes memory it was not a store computer um uh it's the store program computer this is so but it did stuff it had valves and uh and tubes and knobs and was a an automatic computer by default you said computer would refer to a person who did calculation and then it kind of all switched over we use other metaphors as well memory how much memory does your machine have yeah but the funny thing is you know we have somehow detached that and absolutely forgotten that it's a it's a metaphor I mean we don't talk about you know yeah this is this is how we think of memory we think of memory in a very physical sense we talk about its quantities but we don't talk about forgetting okay we don't talk when when we say when we talk about computer memory we don't say oh yes I need this I need it this to be remembered and I need this to be forgotten we mix our metaphors going back to trash cans we have garbage collection and stuff like that that has nothing to do with memory although there are days where I feel that maybe it does um sometimes the metaphor transcends to the point we for it doesn't have any Associated entailment and vocabulary and we even forget that that's a thing so a number of years ago um authored this book um Pat ored software architecture Volume 5 and there was an observation I made in one of the chapters the a physical and invisible domain of software is more about met for than matter that we end up and then based on personal experience if you think about it look look through a piece of code and you will find that pretty much every name is metaphorical not every name there are some names that are actually just names that we have invented for this particular space sometimes we use um terminology we create terminology to describe something sometimes it's an acronym so soap rest all of that kind of stuff these are invented words okay they are invented for a purpose sometimes we invent words to describe our practices and they are not metaphorical devops is a clearly for example a coined word sometimes it's just a simple description continuous integration we talk about cicd pipeline ah pipeline now we're getting somewhere that's a metaphor but a lot of our vocabulary is metaphorical but not all of it there's some bits that are just actually just constructed phrases that are accurate descriptions or other coinages um so as I said this is something that's been of interest for a while run run a few workshops um my friend Andy uh Andy longshaw U this was one at the European patent languages conference um back in 2006 um and uh Andy and I did a right up of that metaphor in software development we ran a similar Workshop the following year at The Spar conference um 2007 you can see kind of foreshadowing of the title of this talk um trying to explore what what metaphors people used but also how well metaphors stood up which metaphors were the most um effective and also which communities were really bad at it we we all came to the conclusion in fact independently in both of the conferences that security people are suck at metaphor yeah um about the only one they' ever got right is virus when we talk about security but the whole idea of a demilitarized zone that doesn't work a demilitarized zone is not a thing that the company owns it's normally jointly owned it's a no there's you don't you don't have the control over it that a DMZ does in the real world it's not implied there similarly you have other things like firewall we have firewalls on our computer but the purpose of a firewall in a building is is not to keep the bad it's not to keep the bad stuff out it's to keep the bad stuff in yeah it's complete inversion the idea of firewalls and buildings is to stop the problem spread spreading throughout the building if there's a fire you want it contained in this space here a firewall on a computer therefore should say okay I found a I found a virus and we are going to just like unhook you from all networks we're going to air gap this computer automatically that's not what happens um firewall is a defensive mechanism against the outside world it's a complete inversion we got it they got it back to front so we had we had a good fun taking the piss out of security people apologies if you're a security person they're still getting it wrong 15 years later but I said we'd see this tree again I don't just use it as my backdrop I mean I I like this picture I take a lot of photographs so the copyright on all the images is mine it simplifies intellectual property um and uh it's a tree well it's a bunch of trees but let's focus on that tree there why are we talking about trees well Donald canth made this observation trees Sprout up just about everywhere in computer science let's talk about this word up they don't Sprout up everywhere in computer science they sprout down I remember telling my kids a few years back I said oh yeah yeah know we have trees you know I was showing them something computer and I said yeah yeah that that's the route that's the but you know trees yeah we have them all over software but they're upside down and my kids are looking at me going like this is one of those things where you're pulling our leg and just kidding us around Dad no no no this is this one's real not like the other jokes I tell you this this is actually the real thing it's just like how could a whole discipline get screwed this one up so badly maybe we should maybe we should have just called them Australian trees I don't know but you know but here Wonder this relates to a wonderful observation from Tony Hall you cannot teach beginners top down programming because they don't know which end is up honestly I don't think that's just isolated to beginners okay but we do other things as well there's you know I've shown you a black and white image there but obviously we know when we think about things when we think about trees we have a color Association and most strongly except for Autumn perhaps we tend to think of them as green do we do this in software well no we don't or yes we do we do have color but we have red black trees which is a completely you know had we been thinking clearly on this one there would have been something I don't know like red trees or something actually I'm color blind so that wouldn't have helped but the idea of if we're going to use color why don't we use colors that are more natural to to trees and maybe perhaps red black trees would instead be green and kind of like sepia tinted trees you know that would have been quite a nice name but the point there is that when we do get around to use color we don't use it in the way that's expected of the original space and obviously every talk has to have an XKCD reference um uh and of course your parents won't invite you back if you start using that my lman quote that I gave you earlier this is a good way to isolate yourself from family now I did this piece for O'Reilly radar a couple of years back uh on exactitude in technical de where I spent a bit more time talking about metaphor and the observation that we need to always respect it will never map its Target perfectly a metaphor is a conceit not an identity because if it were exactly the same then it would be well it wouldn't be a metaphor that's the whole point so sometimes people say oh yeah that metaphor is not is not right that's probably a subjective thing they're not unless you're being very pedantic that's not actually an accurate way of describing a metaphor metaphors aren't about being exactly right somebody oh that metaphor is wrong that's a very judgmental word I don't think many metaphors are actually wrong I think some of them really don't fit very well but they're not necessarily wrong it's not boole and right and wrong um that is a question of identity but we do use this stuff we do actually respect the int we might have got the uh we might we might not respect the color or the orientation but we use this language and we can see it everywhere in fact actually the speakers din there last night there was some discussion of trunk based development and we talked about branches nobody sat there worrying about the metaphor everybody knows what you mean um although if you are totally focused on trunk-based development maybe trees are completely the wrong metaphor to start with might I suggest because the whole idea of a tree is that it has branches um you know it's uh if if you're doing Trunk if you're if you know if you're fully committed literally to trunk-based development then you should be talking about no no no this is a denuded Forest it's it's like it's a wasteland there's only kind of trunks here it's like you know yeah it's not a good scene but nonetheless we use this language we use it all over the place you know we might say oh yeah here's an object structure and the leaf nodes we don't even question that so the language informs us I mean imagine having to come up with words for this stuff if you didn't already have a system of meaning that was available to you and there's an important Point here is that a lot of these things come with this metaphorical entailment if you like it's an association Cloud a tag cloud of possibilities as uh they describe like ofen Johnson described uh metaphorical entertainments can characteriz a coherent system of metaphorical Concepts and a corresponding coherent system of metaphorical expressions for these Concepts so what we're after when we are looking at naming it's not just and this is something many years that I talk whenever I talk to developers whenever I'm running workshops or doing consultancy or just having a chat about code trying to emphasize the idea naming is not merely better labeling okay it's not about labeling I'm not just trying to label something I'm trying to take an idea and put it in your head it's really hard what we're trying to do is put ideas in each other's heads and we're not just trying to put a word we're trying to put a system of meaning or the suggestion of a system of meeting here take this and hopefully some of the other stuff goes with it as well we're doing this by suggestion as opposed to direct communication this is this idea this is this idea what we're doing is we're saying here is this idea and with it comes a lot of other things that I don't have to introduce or that you can deduce for yourself once we participate in the same system of meaning now I hope you've already had breakfast otherwise this picture is going to make you hungry um so what am I talking about here um we're talking about pancakes no we're talking about stacks of course we're talking about Stacks why wouldn't you talk about Stacks the most overspecified data structure in the history of computer science and yet you'd think we'd be able to name this stuff right you know I mean it's 2023 anybody know when the first stack example appeared I'm going to guess it was the 1960s I have read papers the early 1970s I can definitely site that use Stacks but I'm going to guess 1960s so let's talk about these things what do they have well Stacks have a size okay so size is not a bad name okay they can have a count that's also yeah number of Pancakes that might that that might work out so that's a discrete concept it's countable okay that works what about length no that's just stupid length is a horizontal concept Stacks are a vertical concept still freaks me any anybody work with uh python a couple of you right if you want any size concept it's called length well actually called Len because apparently there's a little bit of a there's a little bit of a kind of shortage of letters um going around but we call it Len um we end up with stuff like that so but this is the interesting thing is that there's a concept of there's a there's an orientation just like happy is up sound is down length is not up or down it's horizontal if you want up and down then height or depth yeah but the important thing height is here's the base and depth is here's the base we do it the other way and that gives us however once we've understood that it's a vertical orientation the whole concept is a spatial and vector-based concept then it has a top so that's the natural name for the top element yet somehow apis everywhere screw this one up I there are a few that get it right but we've had this crazy idea I think I first really noticed it in the Java API C++ got it right by calling it top Java said peak what the oh it's like you're having a look I can see it's on the top there's no having a look I don't need to have a look it's right there that's the whole point of a push down stack quite literally that is the point the top element it's not the peak element that would be this hang on wa a minute next word Peak that's a different spelling of peak for those of you who's still struggling with the craziness that is English spelling that's a different Peak I mean that's kind of cute there's a little bit of me that wants to call it that because it's like the peak of a mountain going back to mountains they don't have fronts but they do have Peaks no that's really bad because it's too clever it's too it's just not where it is and then you have this kind of fetish for putting them a get in front of everything can I just remind you that get in English and this is also for the first language English speakers as well they forget as well get in English means modify the state of it does not mean I'm asking you a question it means please have a side effect on this object okay so if I go to a cash machine if I go to a girl Alat which I have to in Germany because you guys have not yet gone fully cashless it's quite bizarre coming to Germany just like oh I need cash again um so I have to go and get money from a machine and you know what that has a side effect on the machine on my wallet and on my bank account that's a huge side effect if you get married that has a big side effect on your marital status and other aspects of your life okay so the point is get means change the state of just in case you want to have that debate at some point at work what does get top mean we don't get top is a movement it's it's not a it's not a value it's not a thing it's not it's not there get top means well we We call we don't call it that we call it pop and they are called push down Stacks because the other one is push that's where that's where the whole idea comes from so there's a system of language and you think that we understood it but because it's right there and we don't pay attention this is the important thing when we come to understanding systems of meaning remember when we talk about domains there are many domains and one of them is the the infrastructural stuff that we built and we are often responsible for naming this stuff and therefore the domain comes from within technology and it comes from within us and our decisions we're not necessarily going to talk to somebody to really discuss this in terms of somebody else who might not be a software developer this is our own space and sometimes we're not very good at it I mean this gives rise to Phil carton's classic observation there are only two hard things in computer science cash and validation and naming things so if you struggle to name things what should you be doing well here's some of my dictionaries and some of the books that I have on Words you know I I know people who make a actual point of like yeah let's get dictionary let's have a team discussion around this okay other ways of dealing with these problems I a wonderful suggestion I think uh I got from Barney Dela uh a few years back um is that whenever his team whenever they kind of like team or Ensemble programming whenever his team coding they can't come up with a name for something they use a keyboard Smash and eventually people get tired of referring to and event you start hearing people actually draws out the vocabulary yeah but working with a dictionary so you know what I love is that a dictionary is ultimately self-referential because it contains the definition of itself yeah so uh it's it's yeah a look uh a book that lists the words of a language in alphabetical order and gives them uh gives their meaning or the equivalent in in a different language obviously when it comes to software we're not really worried about the second part but I'm just going to tell you there's one idea here one idea a dictionary has a well defined ordering let's go to the net Library let's iterate through addiction the order in which the items are returned is undefined what one job people one job there is only one thing that dictionary means and actually we can I know which who we can blame this for small talk cuz a lot of people oh small talk it's so beautiful it's so pure and all the rest of it yes but it totally ballsed up some really basic points about how to name stuff so the point is the idea of a dictionary that is unordered that's not useful that really is not useful just you pause for a go yeah yeah we could have done this one differently there's lots of alternative names so if we're looking at systems of meaning let's let's let's try something else let's just see where this one takes us and explore this idea of different idioms and different entailments okay that's a source that's a SN what's the thing in the middle all right did you say SpaceTime decoupling well done because that's what it is isn't it it that's the actual description think about it pause for a moment and that is the most accurate description of what it is it's not a metaphor it really is what it is it's a space time decoupling what do you use Q's for just think about every single q that you've got it's it's either related to space or time decoupling or both oh yeah yeah I never thought about like that's that's provocative as a way of thinking it's just your colleagues probably won't thank you for this okay yeah but if I use the term source and sync then it's natural that I would call this a pipe but if I shift the vocabulary that doesn't feel quite right so we'll shift that one again to that so notice there's kind of like these little kind of systems and implications and what's interesting is that in the real world a q being a horizontal concept A Q is a thing that people do and you know different cultures have different ways of queuing um depending on the country that you're in uh it's been often described that uh the English can form an orderly que of one um whereas there are some countries where there is no queuing discipline whatsoever and they kind of it's more like a heap um there are lots of different ways of describing this but what is interesting just look at the two words on the outside producer and consumer that that's a different metaphor because if I'm in a queue in a shop then I am a consumer I'm in the queue the consumers are in the queue yeah this so what we've got is actually we've got two different metaphors that have kind of become so familiar that theyve form a system of vocabulary that is based on a collided metaphor um talk about capacity and we can have various capacities we can talk about things being buffered we can buffers to do with trains bounded tied up okay contained asynchronous okay that's not really metaphor that is an actual description that's a technical term but the other two are metaphorical what is interesting is that when we start messing about with things we end up discovering a few things first of all if you have an unbounded thing that's a really bad idea for a que just generally just just don't have except in Prototype code don't have unbounded cues it's it's it's a bad idea but what if we play with some of the other numbers if you're going to have Infinity you got to discuss one yeah what is a q of one well we don't call it a q of one we use other terminology for example this side of the relationship is often referred to as a future the other side is a promise but you can build you can build a one-time future promise pairing using a one place Q we just don't talk about it like that we use a different kind of idea in vocabulary set we can even take capacity down to zero because of course there are only three real there are only three numbers 0 1 and infinity um or actually no in Computing we are very worried about the word infinity so we just say many you know many we just don't want to we don't look at Infinity yeah it's like the abyss it's just you know there's more there's stuff potentially in infinite zero1 what does it mean to have a capacity of zero well it's unbuffered it's synchronous actually the term that we've ended up using for that from Tony hor CSP is that's a channel a zero Place pip or Q is by default a channel you get the same kind of concept if you're working in go by default but you can actually make those buffered in which case they cease to be what was historically known as a channel the idea of a channel historically was it was a synchronization point a rendevu point so we kind of there's an exploration there how do we talk about these other things what are the actions that we use add and remove that's kind of very general collection type language that doesn't feel it's not wrong it but it kind of doesn't have quite the right suggestion the fact that I've got arrows on my drawing suggests I want something that implies flow push and Pop I can I can borrow from Stacks but that feels a bit weird although I do see some cues being push and pop this one describes the control flow that's not bad I push onto it I pull from it that kind of you know and we we see that language as well when we talk about pull driven systems and so on push notifications and all the rest of it so there is an implied notion of flow notice what I'm doing here is I'm exploring the language of flow of movement there's a suggestion there I often end up with these because it's so neutral in other words sometimes you just say you know what I'm just going to use these because they are obvious to do with cues and it stops me worrying about uh all the other entailments that might not be appropriate so maybe that gives us U following Java you know we can we can talk about that we can sort of see that there's a length idea there's a Capac it's horizontal but there's more to this as well if we want to understand this as a system so this is a book I edited a few years ago 97 things every programmer should know it's it's it's a uh it's actually an Open Source book you can find various versions online every now and then somebody emails me and says Hey Kevin did you know somebody has pirated this book and it's just like no no no it's perfectly fine there are G there are lots ofit book versions out there um I intentionally made sure the license was available for that lovely piece by Nicholas Nelson thinking in States in most real world situations people's relaxed attitude to state is not an issue and people do have a relaxed attitude to State and we find it however in technology as well unfortunately however many programs quite vague about State 2 and that is a problem I find this in so many cases like a company I visited U I did some consultancy at um almost every visit that I ever did with them involved me at one point saying let's just draw up a state diagram because everybody was focusing on the code and the names and the structure that they could see and if they drew any kind of diagram it would be either some kind of deployment diagram or some kind of class diagram with a suggestion of object instances but nobody ever actually said what are the states what's the life cycle of this thing and in doing that I found so many problems or clarified so many things uh one one particular company there was a disagreement in the room we had about six or seven people in the room including the project manager and we were talking about the development of a client side app that could work in a connected and disconnected State okay and therefore in when you reconnected it there should be replication of state and we seem to be going around in circles trying to describe what was going to happen and I suddenly thought I'm not entirely sure we're using the same words or rather I'm entirely sure we are using the same words I'm not entirely sure we're using the same meanings so I went and Drew up a state model and the project manager said that's not what I was thinking so I then Drew up his State model everybody else pretty much in the room okay now I see what we're doing okay so now we have a choice between now now we changed the discussion a choice between this is now a design decision discussion except for there was one guy in the back of the room said actually I wasn't thinking it was either of these two it's amazing just drawing something can bring this out but we find this in many cases I find so many bugs in the real world when doing this one of my favorite ones was a a hotel in Istanbul I was doing something for a company and I went there and it had one of these um uh sort of two lights outside the outside the room one light said please stay away I'm sleeping the other light said please come in and clean my room and therefore you can look at this and go each light can be on or off and there's buttons on the inside now think about it for a moment you're going like yeah yeah that's cool except there's one state that should not be allowed there are four states that implied but one St should not really be allowed come on in I'm sleeping that's not right that should not be allowed and guess what it was I so now every time I'm in a hotel room that's like that just check it about 50% of them get this right and make and and recognize there's an illegal State transition and you're not allowed to do that I also do it with lifts I found a number of bugs in lifts and in cars and it's really funny when you're in a lift or a car driving and you say hey there's a bug in the car's um uh engine management code and you're with somebody and you demonstrate it they look really worried there was one in uh a lift a few years ago uh this was in Bangalore and I remember spotting it and on the way to breakfast I worked out what the situation of the bug was and I said ah right yes you end up with a there's a reset at this particular point so therefore it always goes to ground and therefore you have to go up again and you know so ended up 5 years later in the same hotel and I was with a couple of other people a couple of other developers and I said hey there's a bug in this lift you check this one out and both of them are kind of like what you know and I was able to reproduce the bug mostly it's to do with what is the state of the system so we can actually see and start visualizing this stuff and understand the richness of this system of of words we have the notion of data flow we have the notion of control flow NQ and dqq have a different flow to the data flow which is left to right but we also have these ideas of capacity and length and we can visual that easily we can go further and actually draw up a state diagram should we wish to sketch it out because most of the languages that we use are not very good at state state is not a first class concept I'm not talking about stuff that's held in fields I mean kind of a macro state of behavior but actually if we're going to do it properly then we realize there's a much richer version and therefore we have to start constructing certain words ourselves because it feels a bit picky but the problem is that there are these other states there is empty and non-empty and that's not an easy that's not a convenient word is that you know I have a non-empty glass yeah that's kind of a bit clunky in terms of English but then we also then introduce non full as a distinction I mean we strictly speaking non full up here is non-empty and non full but we have to draw a line somewhere but here we are constructing from an idea and some of the language we're using is constructed and goes beyond the metaphor but we also achiev really good alignment you can actually map that structure directly through to some tests and the tests have exactly the same nesting structure as the Transitions and the states in the other in the other diagram and that's how to really think about this what we've actually achieved here by understanding and using our own vocabulary and and messing about with the choices of words trying to describe okay what do we uh what do we what language are we going to use um a non-mt q that is full ignores further Ed values I've chosen to use ined there I could have chosen reject but that felt a little bit strong so I'm going to go for the idea of ignoring because it's perfectly fine and it's not an exceptional condition so therefore the language that we then use suggests certain things if I use the term reject I'm expecting an exception or I'm programming in Python just for those of you who don't program in python python just says exception you're pretty much for everything even ending Loops you end Loops by the underlying mechanism in Python is it raises an exception which is why you should never get a python programmer to help you park your car y back up yeah yeah you're good you're good you can stop now yeah they wait till something bad has happened and then they tell you to stop so there is a whole idea here that we've got effectively we've achieved good modity but that idea obviously starts with the idea it's not just about the names we've gone a lot further and we've also applied it to our own sisters um if you not come across commit strip absolute absolute hoop this uh com com strip data to generic anybody got a variable called Data in their code yeah yeah apparently um so Peter Hilton did a kind of a a search of GitHub a few years back to find out what the most common variable name longer than one letter because obviously it' be I um longer than one letter was and data was the most popular second most popular was Data 2 the sequel yeah data DB un clear let's say List complete already used array list data completed that nah we must choose now the client might cancel the project well array list completed form without duplicate too long yeah unable to name variable they go bust yeah not yet happened to the best of my knowledge but you know that we do I don't think you can spend too much time on this or rather to recognize that what you're doing is you're not just trying to find a good name you're trying to find a good system you're trying to find something that fits together and sometimes you have to step outside the names that you have to make it work and you end up as I've already implied there are there are these um systems where we end up with a collision uh one of the focus group uh discoveries was there was a general consensus in the focus group that metaphors could be high expressive but to actively seek them might be too forced or the result too contrived okay we're going to have a metaphor meeting this morning we must find the right metaphor for the system now that sounds kind of like a bit of a joke but actually it kind of happened a bit with XP extreme programming there was one of the original 12 um principles or PR 12 practices right there in the midst all these other things was metaphor and it was quite interesting because this was something that at the time teams trying to adopt XP and it's interesting just to say that in the second version of XP the New Testament book um metaphor was dropped not because metaphor is not value but you can't consider it a first class concept um as we must have it the idea of the system metaphor will replace architecture that was kind of Kent's kind of focus it replac now the problem is architecture is already itself a metaphor there's lots of different ways of describing that but to say we're going to have a system metaphor a unifying metaphor for the whole system is problematic because first of all you're assuming there is one metaphors just don't work like that that's not how we think we've already seen that in even the most trivial cases we mash them together and are quite happy with the result and we get by but we also have there's another aspect here is one of the things that they discovered is that people start trying to have upfront meetings about what system metaphor are we going to choose right at the beginning before we've even built it in many cases a metaphor will emerge if you hardcode a metaphor and all of the implications and therefore the structure in place right from the start before you know what you're doing you've actually squeezed the life out of the very process that you're trying to encourage so it ends up being dropped now there's an interesting point that I want to come back to on DDD CU there's an interesting thing that a quote that I've used a number of times I've seen a number of other people use when talking about this question of alignment there's a there's a number of different ways of reading this domain experts should object to te terms or structures that are awkward or inadequate to convey domain understanding developers should watch for ambiguity or inconsistent inconsistency that will trip up design notice many people will assume that this is all about Discovery and that is part of it trying to understand a system of meaning is partly about Discovery but it's not just about Discovery if you actually look at this carefully you can actually see that there's an implication that not everything is just out there there's not only Discovery there is actually creation a lot of the time we're actually creating the things sometimes if you are talking to a client they don't have a word for something that is incredibly ordinary to them because it's so incredibly ordinary why would you even bother talking about it yeah it's just something that they don't notice or a distinction that does not matter to them or that is context not bounded context relation uh uh but context specific sentence level specific they don't make a distinction or a distinction is emerges from the Legacy but is actually not a helpful one to think about and they're offering alternative term might not contradict them but it might help to clarify it's not just the concepts that are out there it's actually reflecting back it's an AC of conversation you're reflecting back and you're not just giving them back the same words you're giving them back a new system of understanding as well so there is a lot of creation here and so therefore caring about metaphor is what allows us to sometimes Bridge these gaps to find the new words or to stitch our different systems together obviously we do this together and therefore there's the term network but let's talk about another thing because I want to talk I said right at the beginning of the talk my own personal interest goes back a long way I was um you're assuming I have eyesight but I'm going to I know what the uh I know what the time is um and I it occurred to me this morning slightly depressingly this was 30 years ago I was working on a code base and this is where I had the Epiphany oh crap it's all metaphor you know it's Turtles all the way down no it's not Turtles are a metaphor as well it's all metaphor and I was working on a code base and uh C++ code wrapping C code we were using the word we were using the word network in fact I like the fact that socket is itself obviously a metaphor um we were using a network but we had a number of different uh networks in the code there was the network here and if I go to the OED says yep Network a system of interconnected computers that meaning came to us in the early 1960s that's when that started being used so Network in that context started being used in the early 1960s so we had Network meaning tcpip Network and of course that leads to the notion of distributed systems and I guess then we start moving to a slightly different space with entailment when we talk about distribution we use different language and we defined it in poser 4 distributed system is a Computing system in which number of components operate by communicating over a network okay so you know that that's we kind of raise the idea of distri we say network is this level distributed system is at this level we make a distinction between Network and distributed system however Leslie lamp ports def is always the best one a distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable and so my publisher had this one a couple of years back uh fire in California can't read your book ebook in Pennsylvania um yeah so uh yeah we have all of this kind of stuff but there's another term Network that was used in our code funny enough this also dates back to the early 1960s and this comes from math yes I am British so it's math it's not math um you get more for your money a graph especially a diagraph in which each Edge has associated with it non- negative number now it turns out the 1960s were people really got into this whole graph and network stuff you know there diagrams like this this is a network that features in this book by Christopher Alexander from 1964 notes on the synthesis of form Christopher Alexander is the guy who BAS basically came up with patterns that's the 1970s thing but in the' 60s everybody was obsessed with that kind of diagram like this one another one from 1968 which comes from a fairly well-known paper by Melvin Conway um and he was using this we found these ideas all over the 60s people are drawing like yeah yeah networks networks that's the word we actually see an uptick in the usage of that language but the system I was working on so we had Network for tcpip Network we had Network as a data structure a generalized data structure so following the math tradition but the system I was I was working in the power industry this is electricity we also had another it was when I looked at the code and thought wait a minute we've got three Network we actually had four or five different things called network but these are the three that I specifically remember because of course there's the electricity Network you system of cables for the distribution of electricity to Consumers this dates back to the late 19th century okay interconnected electrical conductors or components sometimes including a source of electromotive force that provides more than one path of the current between any two points so this is a sign on a substation you danger of death but this is you know you get your electricity and you get stuff like this which is quite useful you can power stuff and we talk about that so we had multiple forms of the word network now at the time one of my colleagues was thinking of this as just being a name spacing problem whereas I was sitting there going like yeah but none of these are actually a network because what is a network if we go back to the 16th century I did promise the 16th century earlier work in which threads wires or similar materials are arranged in the fashion of a net well in other words it's to do with fishing it literally is to do with fish and so that is the that what informs all of that so Network itself is not so much a metaphor but a more of a simile but it is metaphorically inspired it's by analogy oh like a net and we've ended up with this whole vocabulary much of which has gone Way Way Beyond um what we qualify as a metaphor so I'm going to end with a couple of points here to be good consider good a metaphor has to offer a number of points of useful correspondence with what is being described another quality of a good metaphor is that it should not have too many obvious points of conflict it will never be perfect and the third familiarity to its audience so we can look at Just One Last system here so um uh welcome to brexit Britain uh this is our new technology program um it's a legacy system we're not entirely sure what it does but it seems to work twice a year we don't know what the original motive of the developers was we don't know who they were they've since moved on hopefully to better companies but we do have the language of Legacy spaghetti code which kind of works as kind of a cute description but then people start coming up with but it it's not a description of something that's bad I quite like spaghetti and then people come up with they try and play with it and they say yeah yeah lasagna code is much better because it's layered and it's is like well you're telling me that that implies lasagna's good spaghetti is bad not in my book I prefer spaghetti and then each generation rediscovers ravioli the latest generation are going ravioli microservices the generation before them oh ravioli that's components oh actually no the generation before them was ravioli is services and these days we have microservices which are actually larger than the services were but maybe we've messed up the word micro as well and then we had components and then we had objects each generation rediscovers this and then we have things like code rot software Decay these are natural processes but the problem is they don't have the right entailment because they if I leave my code alone for a while it doesn't rot or decay ones don't Decay down to zeros or 0.5 or anything like that they're just as they were so the problem is it lacks agency entropy I always thought was a really good description measure of disorder the problem is it turns out that unless you've got good knowledge of physics then this is not a good metaphor because then I have to explain what entropy is so I'm going to explain something abstract in terms of something else you don't know at no the same applies to technical Deb we'll get back to unhedged call option if you're in fintech this makes sense if you're outside fintech what the doesn't help housework that's quite a good one so you know we can actually see that there's a number of different points here that we can kind of walk away from but when we look at this stuff there is a an explicit recognition of metaphor Martin Fowler helped popularize this idea although Ward came up with it about a decade before technical is a wonderful metaphor to veloped by Ward Cunningham in this metaphor doing things the quick and dirty way sets us up with a technical debt which is similar to financial debt the problem is that Martin used the term he used it extensively quick and dirty that has a negative association so in people's minds they started going around going yeah it's all it's all bad yeah so we end up with this kind of idea that that's but that's not what the original plan was Ward wanted us to reason about our code he was talking about he said the whole point of the debt metaphor back in '92 shipping first time code is like going into debt a little debt speeds development so long as it's paid back promly with a rewrite notice he's describing borrowing it's not debt it's borrowing but we focused on the wrong detail he said obviously don't be an idiot the danger occurs when the debt is not repaid every minut it's spent on not quite right code counts his interest on that debt and I'm going to skip that slide so technical debt the issue with technical debt is when people say oh we have a technical debt problem I'm kind and well Kevin we have technical debt is that a bad thing they kind of look at me like I'm an idiot I could well be an idiot but the problem is they haven't said what their problem is they have an unmanaged technical debt problem if you have a te if you have technical debt that's not necessarily of itself a bad thing so there is an idea here that we often confuse these things we I miss we confuse these this notion and we get a little bit closer to it with a house metaphor my theory of tech debt is housework is the correct metaphor for the thing we call De Tech debt but we can't use it because Tech has been made up of people who don't do housework or manage housework being done and what we actually see is that there is a confusion we often people often say yeah we they're focusing on cause but Tech debt is not a cause of a problem Tech Deb is an effect or to be precise unmanaged Tech Deb so when people say we have a tech te debt problem most of the time they actually mean they have a technical neglect problem that is that is more accurate metaphor it's not that they don't have technical debt but the problem they have is there we actually see this we actually go back to my Lan he talks about it as an evolving program is continually changed its complexity reflecting deteriorating structure increases unless work is done to maintain or reduce it notice how what he uses he talks about this as maintenance but we have ended up using maintenance as a different word the correct word for we end up using maintenance for Feature Feature extension and Bug fixing whereas he's actually talking about maintenance in the sense that is actually most like the real world form and maintenance is an action what we're trying to do is identify inaction for which we have a word and that word is back to this neglect so in that sense we can actually see that there's whole kind of system of possibilities that we see in this so in closing although a metaphor May successfully capture a part or some aspect coverage of most Concepts is improved by explaining them through multiple metaphors the idea working with mixed metaphors is the norm rather than the acception we should remember that we're already abstracting when we do this so we're not going to end up with a perfect metaphor mapping and sometimes forcing is going to be difficult but we should also remember that we are a couple CP of levels removed so I will leave you with a useful word petaphor an unusually extended metaphor where a figurative expression or contrast is made against a metaphor rather than against a reality in this sense we can say a petaphor is two levels removed from the reality described which is a little bit closer to what Layman was describing and we should be comfortable with that level of indirection but we should also be aware of it and understand that sometimes we want a little bit of the looseness that comes with that but sometimes we need to push back against it but it always has consequences in terms of meaning and how we think thank you very [Applause] much