What Do You Mean? - Kevlin Henney - KanDDDinsky 2018

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
[Music] [Music] let's start it's the slot after lunch okay so all I'll talk about what we mean we had a actually very interesting example which I'm gonna come back to all the relationships they're about 90 seconds ago a bell went that Bell has meaning okay it's a bunch it all all it is is the Bell is a sound that is in it is that we can understand the physics of it but it has a very particular meaning and that meaning is utterly bound up with context where you immediately wakes up all context he's gonna talk about bounded context yeah maybe I will maybe I will talk about a lot of things and will converge on meaning this is the polite version the less polite version is honestly what are you talking about what do you mean so there is this question what do we mean by software systems and stuff and I love this bit that Maya layman wrote a wonderful paper from 1980 programs life cycles and laws of software evolution any prior there's a lot of good thinking in here but I love this bit this little paragraph every now and then you can find a just a sentence or a paragraph that somebody clearly had fun writing any program is a model of a model within a theory of a model of an abstraction of some portion of the world of some reuse universe of discourse it's just I I love this it's just like okay so you just snuck that one in there is an otherwise relatively dry but very informative paper now we also mess about with this stuff it tells us where there's an awful lot of process here how are we going to get the answers that we need but there's this other thing called abstraction abstraction is one of these words we throw around an awful lot I run a lot of workshops and one of the things I ask people and they often did depends on the kind of the nature of the workshop sometimes people will put up things that say Oh abstraction high level of abstraction and this kind of stuff and I often ask people well what do you mean by abstraction what does the word abstraction mean or abstract or the verb to abstract what does that mean and then kind of people look at each other and they come up with all kinds of definitions very rarely are they right there's normally value judgment already embedded people say oh you you know abstraction is when you emit a relevant detail no it isn't abstraction is when you emit detail if it's good abstraction it emits the irrelevant stuff if it's not going to notice that there's a difference between the value judgments they're really very subtle abstraction does not another a good thing or a bad thing it is merely a thing it is the removal of stuff yeah Lattin apps tray here a draw off water that's literally what it means abstract art removes reality abstract classes remove implementation this is what abstract means and we have a real problem with language because a lot of people wander around and I get this oh yeah yeah yeah we're we're really high level we're close to the customer you know this is there we go we work at a high level of abstraction really that's a very strange way of looking at it talk to a customer talk to people who don't do programming what they regard as programming they think of as highly abstract when we talk about low level of abstraction what are we talking about we're talking about oh you're close to the machine when they talk about the machine they think it's abstract in others we got the world upside down if you really do believe in domain-driven design you should be working at the lowest level of abstraction possible that is the customers world yeah it's such a programmer centric thing to say yeah we're working in a high-level abstraction with the customer's language and concepts that's not high that's really really low you're trying to get close to them it is not that we're using the wrong orientation we're using a vertical orientation it's actually distance we are far we are near it's nothing to do with up and down okay language is very tricky and it deceives us but it this is also least a reputation where we end up with just being a bit vague Dijkstra made it very clear purpose of his trash it's not to be vague but to create a new semantic level which one can be absolutely precise now I've just used the word semantics there and this is one of those things eventually you will end up in a debate it will either be over beer or it will be over politics or it will be over code and somebody will say oh that's just semantics and it's just like you'd it's like you just dismissed it oh it's just semantics what is semantics semantics is meaning it doesn't what it's just meaning it's like well what else are we working with did you have something else in mind you know what what is it that we're doing here what is this stuff software yeah there's a lot of different ways of looking at it but one of the things you're trying to do and constructing is you're creating a system of meaning and you may use metaphor you may use all kinds of things but you are creating a system of meaning the more coherent that system of meaning is the easier it is to navigate and the less surprised you will be the problem is that we build these things over time so we have our early understanding mixed in with our recent understanding so we have this stuff called code and then when we start looking at code people have a very different set of takeaways when they reason about code or when they talk about code you can find this when you ask people about the programming languages they use and for many developers when you say code they immediately think of the thing that appears immediately in their IDE and is their favorite programming language always the first programming language they will put down on their CV and they'll say Java they'll say c-sharp so Ruby they'll say whatever yeah that is code but so is that oh and so is that and the config files and the these are all code these are all code yeah oh we solved the problem by putting it all in XML it's not a coding problem oh yeah have you seen XML honestly really oh yeah it's fine XML is human readable what kind of humans were people talking about when they said that stuff but what we do have in across all of these codified forms is what you're doing is that the system of meaning the development that you've got and particularly where you're dealing with a team particularly where you're dealing with multiple developers over time who may never meet each other is what you're dealing is with codified knowledge it's a nice play on the word code but it's a another way of thinking about it our code base is codified knowledge this is what we know or at least what we believe perhaps it should be called codified belief but codified knowledge this is what we believe and this is our system of meaning now when you look at it like that that's something I've been ssin this to a couple of teams they've got a little bit depressed because they said oh you mean that's our knowledge wow we're a mess this is what we know we're all over the place we believe half a dozen contradictory things simultaneously yeah here's what I believe today what I believe last week what I believe last year and what some other guy who I've never met believed ten years ago and it's all kind of smashed together at the same time so I have a conversation with a flat earther so but when you start looking at it like this it's suddenly really suddenly realize oh okay this is it's a knowledge base that's what the code base is it's an it's effectively an understanding of here is what we believe was supposed to be building and here is how we believe we should be building it it mixes these worlds together it also means that the very process of development gives us we already know what it should look like and this is kind of an interesting one people often say well you know develop a process of using Kanban we use and scram whatever you know we be agile with being fragile what are we doing and actually that's asking the wrong question if the goal of software development is to codify knowledge in an executable format then what we need is knowledge acquisition and retention but what we need is knowledge acquisition please use this term when talking to others particularly with who have paying power because it sounds good okay so what you know what so tell us about your development process oh we're using a to establish a model of a model within a world of discourse we are using a process of knowledge acquisition okay you've got the contract sounds good those guys really know what they're doing yeah the rest of us just say oh it's learning it's a nice short word but knowledge acquisition sounds that little bit better okay there's a little bit of extra stuff in there a little bit Latin as well now I think it's how do we get learning around this starts telling us it's an act of communication so software development ultimately involves an act of communications one of the ways one of the many ways I can transport my understanding to you is communication now this is in the code it's in the team it's in the air it also means that what you are building in a code base what you aren't doing is social negotiation the very act of creating a code base is social negotiation even negotiating with yourself over time if you are just on a personal project you will find you have to argue with yourself there was past you and there's current you and there's future you who you have some really high hopes for but you know those will be disappointed you are negotiating the language that you're choosing the boundaries you choosing the choice to partition or coalesce and this also has an interesting consequence it also means that the number of these decisions of structure and meaning create a model of participation they tell us how we're going to work together how we're going to work over time the more formal obviously this sounds a little bit fluffy if you like something more concrete just call it software architecture but that's what it is it's a model of participation that's one of the many things that software architecture can be considered as now all this is well and good and let's just sort of leap over and say well software architecture I've always been interested I'm always interested in metaphors because their metaphor comes with a set of meaning oh yeah okay architecture and people have various debates about all do we do architecture is it like building architecture we have to sing with engineering and all the rest of it one of the few things that people actually do when they have these debates is actually going to find out what these other people do so a few years ago I did actually sit down and read up on a whole load of stuff that building architects do then it turns out that a metaphor is not an identity it's not the same as it turns out that we borrow a lot of good things we borrow some things incorrectly because we think we know what they do yeah that this that very common share belief in a shared experience oh I've seen buildings I know what architects do I've walked in buildings I know what architects do my wife used to have this she was she was a primary school teacher and she said all the parents thought they knew how to run a school why because they used to be a school when they were little you know what that doesn't actually prepare you bizarrely enough you kind of have to go and find out I remember going into schools to see my wife and it's just that wow this is so different seeing it from this site yeah it is fundamentally different so there's a lot of stuff we we caricature because we think we know and then there's a lot of stuff they do not only that is different but it's the same or that's a really good idea why aren't we doing that so this is an interesting book 101 things I learned in architecture school by Mathew Frederick it's actually about building architecture it's a lovely book it's it's it's one of these books that makes you look sophisticated smart and cultured and not just some kind of software geek so buy it leave it lying around and people will immediately think higher of you christmas is coming so I and I honestly I wish I were I wish I were on Commission for this I recommend it so often like every now and then sir oh yeah I got that book it's really great it's got like a nice picture on one page and then on the opposite page you know so I soundbite or get a couple of paragraphs and about half the advice in here applies to any design based discipline anything where we are creating something ultimately for utility and for use okay so about half of that you can take immediately oh yeah this is a different perspective this is useful in fact a friend of mine had the interesting situation he bought he ended up buying two copies because he bought it that his wife stole it off him because she's actually a building architect somebody doing this you know it's much more used to me so you had to go and buy a second one now in this one we got a quote from the finnish architect Eliel Saarinen always design a thing by considering it in its next larger context now this is important because this is we're not just simply considering what is the context we are saying what is the thing around the context it turns out the context is where most of our meaning comes from it is also where much of our misunderstanding comes from it's also surprisingly hard I always been a big fan one of the first things one of the first diagramming notations I was taught was Jordan notation and it had context diagrams and they that was a really big thing in the structured era and then they kind of got left behind and it's just like oh because those are not object oriented well they're not anything they are context diagrams they show you a picture of the world around your system they're not anything oriented yeah but where in the world does this system live what are the things that we want to do with it because it turns out that meaning often arises from action and meaning often arises from consequence of action that's how we under that's how the Bell made sense okay but this larger context turns out to be surprisingly hard to deal with but always design a thing so let's get the word design and so design by default when we think about it it is an act of synthesis is synthesis is putting together you're creating something the opposite of synthesis is analysis you're putting something apart and historically it's software developing we've had a very uneasy relationship with these because they've often gone with the idea of our analysis that is understanding and then there is building and these two are separated from each other whereas it turns out that they are actually in a sort of a salute moment it's like more symbiotic relationship in fact they're in a cyclic relationship the best way to look at these is sometimes I try to build something I take a look back I understand it I understand something by looking at it and then I try and build it and then there's this rather nice cycle it is much like a heartbeat systole II which is the contraction of the heart and the muscular diastole so in other words there's a heartbeat here you're supposed to repeat it but I am also reminded of a interesting thing I was teaching somebody many years ago as a tutor and and she was doing a diploma in computing and she couldn't understand why she'd got such low marks for an essay of hers and it was an essay where he was supposed to talk about development process and when she came to the talk about the waterfall process she said the waterfall process you know the sequential development process is defined as implementation followed by analysis followed by design like today and she said well yeah you build that you go ahead you just throw some code together you build it and then you analyze what went wrong and then you then you design the right thing and I said I said at one level you have you have revealed something truly profound and real but that is not the answer that was being sought by instructor but yes in one sense you are right but it's the notion that there is this kind of rhythm there is this cycle there is this breathing oh this is an activity that we find it's not unique to something like software Ernest Hemingway in moveable feast lovely book he talks about the only kind of writing is rewriting there are other quotes within the writing community writing is rewriting you know this is and it's a it's a really interesting idea I in my spare time I write short fiction and so I'm always interested again in drawing the parallels between that and how I relate to code and there is this notion of writing is nothing without revision the idea that we do this with software that that we've actually had to make a case over a period of decades for things like refactoring and revisiting systems because we learn when you learn you revise your understanding learning is not merely cumulative it is also revisionist you change your understanding you unify concepts I found in fact with my youngest son one day walking back from school I said so what did you learn at school today and he said he described various subjects are certain he likes maths so I said oh so what did you learn in maths he said all we did ratios five to one two to one okay so how was that I said it's kind of boring we know this already dad this is percentages and fractions and decimals it just looks different in other words he had reached that point where suddenly it's like oh this is not for ideas it's one there is only one idea here okay and but that takes time you can't tell somebody at the beginning it's too much for them but there is this notion that learning is in this sense it is not merely you add stuff we keep talking about adding stuff in software we don't talk enough about this natural process of revision it is a natural process it's not something weird and so it's kind of interesting we can look to the world of writing this is a book on screenplay writing by Robert McKee it's perhaps a little formulaic but there's some really interesting insights in here and one of the ones I one of the insights I love as if a plot works out exactly as you first planned if you're not working loosely enough to give room to your imagination and instincts this is a lovely way of looking at it it's okay I know not everything goes according to plan but there is this notion this kind of an alternative way of thinking what if everything did go to plan you might feel satisfied at one level but in another sense you have been deprived of something oh we learnt nothing it's just like what happened I find even as an also as an author one of the most interesting things is when people tell you what they think your story means and ah it's great and I was given a piece of advice by somebody many years ago you just nod your head okay because if it means that to them we're good but sometimes you do not know the meaning when you wrote it honestly you have ideas and then perhaps a little bit later you come back to it yeah there's a thread there's a concept here this is this is this kind of story I something I also do spoken word I read and sometimes it's only after I've read something that I truly understand what my story is about and therefore I will emphasize that more strongly in a future revision this is not different to software okay the meaning the significance that a software system may have for somebody using it will change the world in which they are in that's important okay so this is but this idea of working loosely now this is kind of an interesting one because I I do quite like words and meaning here's a mild obsession of mine I run a page on Facebook called word Friday and most Friday's I will put up an unusual definition a word with an unusual definition and the rest of the week I just post language and vocabulary related stuff but one of the words I featured a few years ago is one used within the writer community is Pancer which has nothing to do with tanks Panthers or anything okay it derives from a very different phrase it's a writer who writes by the seat of their pants they have no idea what's going on this was characterized I am afraid I can't attribute the author correctly but an author was asked by his daughter daddy why are you typing so fast because I want to find out what happens okay the very the act of discovery this is a really important thing you by doing it you are learning about it it is this same kind of heartbeat what is the story about well let me write it and then I'll tell you I have some ideas but as I write them the ideas start taking they're taking on a life of their own and then I see interactions that I did not see before because I'm now working in detail software is always about this along with oh it's just meaning or it's just semantics another one that people throw a throw around is oh that's just details that's honestly what did you think software was that really is all software it's lots of details put together in a way that works there's no hand waving when you come to actually do this stuff oh you know what I mean no I don't the compiler you know what I mean no it doesn't you are committed to detail many of the things that people experience that are mischaracterized as coding errors or coding oversights are actually what they've done is they are trying to pushed something to a level of precision that only the programming actual programming is revealed but sometimes they're asking harder questions of the domain and the world around to which we have not even thought to ask okay so it's a process of discovery as well as a process of creation the contrast here is with a plotter pantser doesn't work - I have an outline plotter has a very clear outline now we can present this as a very binary perspective I think it's a very it's much more of a continuum writers live along this range but I also find that there's something here in sympathy with what we do in software and there is this very idea that the discovery of meaning is not a simple feed-forward process that you're going to have to start messing about a bit you need to work loosely you need to give rise to your instincts now when we're talking about programming when we are talking about writing we're typically talking about language now the problem is that language is a word that is used in many many different ways programming language highly formal set of rules it is a language but it has it lacks the sloppiness of something like natural language on the other hand you get to be completely precise but you are not coding the machine this is a beautiful illusion a lot of people think oh yeah this is low level the whole low-level thing yeah sir I'm working in Java I'm working at a higher level of abstraction than C honestly from a modern processors point of view if you're sitting in the process of looking up you can't tell the difference between C and Java they are both so far removed from what's actually going on C cannot talk about what is going on on the processor there was a time that it could but you know instruction pipelining cache lines all of these concepts are not available in the language or they cannot be talked about okay it cannot be controlled at that level so there's a whole load of stuff down here it's just like yeah there's some programming stuff going on up there that's it you know you really can't tell the difference between these languages you're not programming the machine you have a formal structure that allows you to create a system of meaning then we have natural language which is a bit sloppier filled with ambiguity Oh has a nasty habit of evolving and sure a lot of people say well you know my programming language is evolved you know talking with somebody said I haven't looked at Java since 2010 I said well a few things have changed and there's a fundamental shift in the style I'm dealing with some C++ programmers again modern C++ or postmodern C++ is very different to the kind of stuff people were doing in the 1990s and people might feel frustrated that the fundaments of their language have shifted so far but honestly if you tried understanding children you know with my kids I've got teenage kids and I'm just very thankful for urbandictionary.com ok you know it's just like I have no idea what he just said yeah I've got it as a half you know I don't have a lot of apps install on my phone but it's just like yeah oh yeah done down with the kids now I understand what he's saying but natural language this that this is a problem because sometimes I had somebody tweet at me yesterday I can't remember what I was talking about this oh that's just a natural language issue Kevin just a natural language issue you have another way of communicating this we're on Twitter what else are we going to do I could throw some emojis at you but honestly you know but then when I start saying language people get ha he's gonna get too ubiquitous language you're right I'm gonna get there here it is right gone now right so ubiquity do you know one of the hardest things in software its naming ubiquitous has a very precise meaning it means it's everywhere it's omnipresent yeah that kind of runs a ground when you talk about a bounded context because what you're actually saying is you know that ubiquitous thing I said it's not ubiquitous it's actually context specific well hang on so the thing you said was context free is actually context specific what do you mean why are you using the wrong words it's a I you know in other words yeah this is non-trivial and this is and I'm not saying you shouldn't try for this but I just want to point out that there are a number of things number of challenges that it's too easy to miss in our goal to create something that is simple we like simplicity sometimes we push it a little too hard we force simple which is a different thing so Eric points out he says by using the model based language pervasively and not being satisfied until it flows I like that it's a lovely way of putting it so notice this is about a language of usage there so there's a really important quality here there's a whole bunch of other stuff as we approach a model is complete and comprehensible okay fine complete comprehensible simple elements complex ideas okay all the rest of that sentence is kind of standard computer science stuff but that flow bit was the surprising bit and that is the bit that makes the difference and unfortunately flow sometimes has a very different opinion about what is complete incomprehensible there is a natural tension there in how we talk domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding developers should watch for ambiguity or inconsistency whichever design this is a laudable aim this is a good aim the problem is we've just put two very different groups on the pedestals and we're saying domain experts are good at this are they hmm and how good are developers at this they're okay and how good are they talking to each other when they discover these things ah it turns out that we have some other issues and this is an expectation perhaps this is an oversimplification so I edited this book a few years ago and there's a nice piece in there by Keith Braithwaite read the humanities okay obviously as some of you put pictures up good for Christmas look Vic in stone makes a very good case that any language we use to speak to one another is not it cannot be a serialization format for getting a thought or idea or a picture out of one person's head and into another's it may support that role but honestly that's not quite how it works and trust me and I'm gonna say as a writer this is incredibly difficult and I'm trying to do this stuff I go to workshops and trying to improve my writing and I think I write better now than I did 10 years ago but ask me again in 10 years and I'll say what was the thinking in 2018 I had no idea this is definitely a journey not a destination because this is non-trivial to say what you mean and to convey that but also have somebody else interpret what you mean is is difficult vector stone also shows that our ability to understand one another at all does not arise for shared definitions now this is really important because often we're saying are we're looking for a shared definition I'm not saying a shared definition has no value but sometimes we say it has all the value we put too much hope into it it arises from a shared experience from a form of life in other words it is a process rather than an artifact you have to kind of experience it you have to be there you cannot merely observe the context you have to be within the context this may be one of the reasons why programmers who are steeped in the problem domain tend to do better than those who stand apart from it so yeah mind the gap between these two things there's another one which are quite like in here from Nate Jackson and the title tells you everything you need to know your customers do not mean what they say here are your domain experts let's listen to them I've never met a customer yet there wasn't all too happy to tell me what they wanted usually in great detail the problem is that customers don't always tell you the whole truth they generally don't lie but that does occur first thing to notice by the way is there's a linguistic thing that we've just done here without really realizing it customers customer with a customer that's kind of an interesting concept a customer now sometimes when we talk about customer it's a unified entity it's an anthropomorphic unified entity that feel free to drop that phrase in it you know conversation what do I mean by that um it's a unified entity what is a custom in most cases we're not talking about one person when I walk into a shop and I buy something that's me being a customer in the classic sense of the word customer and shop but when we are talking about business we are using ideas like customer and business you ever heard people talk about the phrase their business have you ever met the business male-female indeterminate tall short I color it turns out the business is an artificial construct as humans we're great at this we have great imagination but we also simplify the world and it turns out we're good at dealing with other people well sometimes some are better than others but nonetheless we we use that and we project this concept of an individual on to more complex organizations we anthropomorphize and we unify them treat them as a single entity and then make some human you find this when people are talking about the mic the markets the financial markets oh the markets in a bit of a mood today what how how does that even work I mean there's moods that's emotion that's that's stunts that's based on the chemistry of my body and you know I mean sure I've heard things about the kind of drugs that people in financial trading take you know it's not the cocaine but that's probably not what we're talking about there's a notion here that we perhaps have oversimplified the customer so therefore people are not necessarily intentionally lying what happens is that when you meet a member of an organization they are respect they have a particular point of view and if you meet somebody else who also represents that organization they have a different point of view and they will tell you different versions of the truth depending on departments and history and their relationships within the organization it turns out that they are human but the organization is not they clearly use their terms in their context just one hopefully we're comfortable with yeah then it gets interesting they don't tell you everything they leave out stuff and that's the hardest thing to see the thing that is not there when somebody uses a word you go well sorry then they use an abbreviation and sometimes you can do things like a significance check one of the things I find very useful when doing code walkthroughs or when listening to a meeting about business is what words are they what words keep coming up and are those words present in other documentation in the code in the tests you know because these words are clearly quite important and if they're not then it's all as a question there why are they not there the thing that is hard to see is the thing that is not there the omission oh the accidental abstraction damn this this is hard stuff because it involves people they make assumptions what it isn't what is an assumption when do you know you have an assumption this is one of those rather curious things you know when you have an assumption when it is contradicted yeah oh I didn't realize that I had assumed that at that moment you have an assumption prior that you did not know you had the assumption at that moment when somehow okay I had assumed that it was a moment of discovery it was a moment of interaction and things did not quite work out the way you expected it was a mismatch between your model and something in the world oh that's an assumption so therefore whenever yeah remember seeing a project document many years ago said project assumptions I love that I mean if you know how to do that that's fantastic but honestly the best you're ever going to manage is assumption known assumptions so far brackets to be continued yeah this is compounded by the fact that many customers don't actually know what they want in the first place now whilst this is true we have a nasty habit and this is something and I can think way back in my career of this frustration and it often occurs you still see it in online conversations where people will say oh yeah the problem is the customers don't know what they want I have some very bad news for you oh or good news depending on how you look at it this is compounded by the fact that many humans don't actually know what they want in the first place don't pick on the customers it turns out we're all in the same boat yeah honestly we have no idea yeah what do you want out of life what's your five-year plan huh some people do have a fine here plan but a friend of mine who worked in as an estate agent for a while he revealed very quickly that humans you know you'd think okay here's here's a couple they want to buy a house surely they've had the conversation and figured out what they want to buy he says honestly know the number of people who came in and actually agreed with one another or had had the discussion about stuff oh yeah when I said I wanted a front garden I meant I didn't want a front garden or oh the yeah on street in austere parking was important but actually for this area no it isn't it turns out that it's a surprisingly rich and complex thing people really don't say what they mean so I'll stick with the writing of a Neil Gaiman one of my favorite authors he talks about creator he's talking offering advice to people who deal in creativity you have to finish things that's what you learned from you learn by finishing things it's at that moment that you suddenly look back this is why we prefer an incremental forward development honestly for me this is why I prefer writing short stories because I finish more of them I learn once you have finished it and sent it off you suddenly have a slightly more objective sense than you may have had before it is not simply like writing a chapter you finish your chapter what have you learned that you've got another chapter to do you so I know lots of authors who are struggling still to write their first novel and is my ambition to not write a novel I have to say I'm being more successful with my ambition than this but the point is I have learned a great deal by finishing things and experimenting with variations at that point this is complete is it any good interesting I've learned this I've learnt that so there's this idea of reaching points of completion this assists in our learning we are able to tie off our knowledge and say what changed what still is a question here what do we what keeps moving so this is obviously not new advice I've mentioned engineering earlier on I've been this year I've been talking a lot about what happened 50 years ago in fact 50 years ago last week the NATO software engineering conference in Garmisch was a landmark conference that was widely misunderstood but had some fascinating content and it is it presents a group of people who have a very different view than we thought they did everybody thinks how everybody said that the software engineering is like bridge building or it's all about the software crisis honestly that doesn't really happen much the software crisis is mentioned in about two paragraphs but that's it turns out that there was a rich body of thinking and we've been doing these people a disservice there's like radical ideas like the design process is an iterative one yeah there you go in 1968 ok something happened in the 1970s I don't know maybe it was disco maybe it was flared trousers I'm not sure if something happened but clearly we were on the right road there's this idea of there is a learning cycle the idea that you're going to get it right first right if you do that's great you're lucky the problem is we don't yet know what we mean by right also popular in the 60s and this was referred to a number in a number of cases in the software engineering document notes on the synthesis of form Christopher Alexander published 1964 this he is best known for his work on patterns basically imposed the idea of patterns but this was his precursor work and here he was interested not just in buildings but in how things are created what is the process by which things are created concepts are created how does this happen and he makes a couple of observations and I there are two ways to there it's one obvious way of reading we made there for picture the process of for making is the action of a series of subsystems all interlinked yet sufficiently free of one another to adjust independently in a feasible amount of time it works because the cycles of correction and re correction which occur during adaptation are restricted to one subsystem at a time this sounds like a very good architectural idea this has inspired modularity there was a lot of talk about this is how we should think about it notice this idea of Rican and we have a natural boundary within which to do that and yeah our systems can be kind of loose with respect to another type within one respect but loose with another mm we seem to be bounding something here ah yes because he's not talking about any specific kind of subsystem he's also referring to any kind of subsystem it could be a software system it could be a system of meaning things change now the problem however is finding the right boundary because sometimes things change we establish them we have this idea that once I have made a decision then just as in the real world we have this assumption that if I leave something put it down walk away go back pick it up it's still there this is our assumption about the physical world it's a little bit like programming a single-threaded program and then yeah and then you get married or you have kids and suddenly you discover that your basic assumptions have been utterly undermined yeah I'm sure I put it there well yes you did but that's the past dude you know and this is the problem the way that we think about our decisions and we think about our work and we think about our code is that decision which was made it was made you know it's like a sediment it's like a geological sediment and the idea is yo you dick wealth and there isn't there is the act of software archeology and you dig down through it and you go up yep this is where the dinosaurs died yeah and it's just that and beyond that in the codebase there's other stuff and we're not quite sure what it was but it's either still seems to be working and there is this notion of we don't we assume it just gets layered up like that but that's not how it works things change beneath your feet kind of yeah here's a good one about assumptions yeah first rome programmer months 7 8 9 10 don't have names what should we call them second roman program at just number them whoa wait a minute isn't that bad practice to hard code numbers it's fine they'll never change fine September October November December it is then you've ever wondered about the names of the months pause a moment okay yeah it's an off by two error things got shifted around a bit okay but we still kept the names yeah so I I I live in Bristol it's across the bridge from Wales the nearest town in Wales near City is Newport it hasn't been new for centuries but actually it's not an active port anymore but you know calling it the first major city over the bridge is probably not they're not going to go for that renaming yeah so there is this notion that sometimes what you thought was a fixed point it's no longer a fixed point the language moves and I can see that even just little things a system that I worked on a logistics company a few years ago the name of the system had a particular spelling and we don't spell it that way anymore in British English yeah language moves it's the spelling has changed but because that was how it was spelt in the late 80s that's how it was spelt in the early 21st century and it probably is still spelt like that yeah so this idea of meaning and the symbols and the vocabulary that we use the ideas the misunderstands we can have we spend a bit of time in patent oriented software architecture another use the word language patent language but I'll go explore that here this in this book we really explored a lot of stuff about patent theory and ideas that don't generally get discussed elsewhere sometimes people say hey should I buy this book you know if I want to get into patterns disappointingly no this is the book that you want to buy after the other books that you bought and honestly if you're still interested you've survived you've survived enough - this should shut you up okay in other words it's the last book you ever want to buy on patents yeah however we made we made some observations about semiotics which is about meaning of signs and association with symbols in its earliest forms and this was actually to do with patents but I just thought it's a broader point here it's the earliest form of semiotic snow semiology in other words since the notion of meaning here defines a sign as a two-part whole diet comprising a signifier and signified okay the signifier is the expression of a sign the signified is the corresponding mental concept okay so how can we misunderstand one another let's let's talk about the natural language the ubiquitous language how ubiquitous is it so I had a girlfriend a long time ago I'm from I'm originally from London and she's she was from Yorkshire it turns out that English is a little bit different and she might and this is in the era before you know mobile phones and useful stuff like that so one day she said oh do you want to come around on Sunday for dinner you know I'm gonna have some friends around to be really cool if you met them I knew some of her friends bent over I said yeah fine great so I kind of turned up at 6 o'clock thinking I was early if you're in the Netherlands then you're late if you in Norway dude that was so many hours ago we had dinner but she was in a really foul mood and I couldn't work out why and then it's just eventually as we're starting to ease that aren't your friends arriving no they came five hours ago and left Oh yet without used as their oh okay yeah it wasn't the end of our relationship but it was definitely on the downward slide that's just a north-south divide thing we have just used the same signifier and we've ended up with actually talking across purposes of course this never happens in technical tonight and there's a lot of different bits and pieces about these things yeah half - yeah now based on the fact we're in Berlin a lot of you sitting there helps fight yeah sure and you go yeah fine half past one this is they know I'm from Britain you're off by one it's half past not half before but also notice in an assumption here another assumption which is I haven't said that all that why because your current context is the afternoon why would if I said if I said either either interpretation and half to how to spy you wouldn't immediately be thinking oh you must be talking about just after midnight no because your context it turns out that full of semiotic s-- is guided by the context it's not just the sign and the signifier it's and where did this occur where did this occur well it occurred in the afternoon so naturally we made an assumption that we were at this timeframe by the way if you ever try and use you know half to in North America everybody thinks is one yeah they just think it's a piece of arithmetic yeah so the point here is is you've got to watch out for this stuff it's it gets us but we do this as well we think oh well no we're we're technical we're using the right words at the right time to have the right suggestion we've got do we have a ubiquitous language within our own development culture I'm gonna say no we talk about velocity development velocity that people very keen on development velocity when you look very closely it turns out they're not talking about velocity they're talking about speed these are two different concepts I'm afraid I have a degree in physics in my background I cannot shake this because to me this meaning is important velocity has direction honestly the way that most people develop I don't think they they're damned we're going fast yeah yeah but you're going the wrong way yeah but we're going fast you know honestly if you walk the other way there's one things I love about coming to Germany is you know this whole notion and there's clearly a relationship between these two but it turns out that that is a simplification what I've just done is I have taken a magnitude with direction and I've just said don't worry about the direction it's just the magnitude that matters I have simplified it but at the same time it's like we might have lost some really important data there and one of the things I love about coming to Germany is the Autobahn yeah it's just like yes there is no speed limit except when there's traffic yeah yeah so you're heading you're heading into Frankfurt on a Sunday night along with the rest of Germany yeah it's just like oh this is where all the bankers come in on a Sunday night at that point you suddenly discover there is a speed limit and it's context defined it's not formal but there are other things and I discovered one day I was doing yeah I loved it you there you are shooting along much faster speed 150 plums 460 comm towers you think oh this is great and then something black shoots past you it's so fast you can't tell if it was a BMW and Audi or a mercedes-benz you know but it was black and it was fast but nonetheless you go back to being satisfied with your own current speed and you make a mistake if you are satisfied with your own velocity because I have discovered one day heading off a great speed the Sun is in the wrong place I am heading in the wrong direction I would have been better off walking okay but then we say what about notation Oh surely these people all use the same notation well in physics we'd see that oh it also is known as this oh great we've got two notations this is one field then we simplify it further we say no don't worry it's just distance with respect to time now as we go through two steps of simplification we'd lost the direction and then we just don't worry about the changes just imagine it's all kind of like you know straight in other words this is where we force simplicity onto our concepts as betrayed by a vocabulary as communicated by over cab Ranieri and then we have the idea of defining by mission okay some things are defined by their absence okay again these can be surprisingly hard to tell and and then somebody comes along says I don't know a sentence must have a verb and I say well where did you where did you learn that well my teacher and when I was eight - told me that it's just like yeah okay but I'm gonna your teachers unfortunate gonna lose against the linguists they they have a deeper understanding of this your teacher was probably telling you that to encourage you to remember a verb so your teacher wasn't necessarily lying but they were giving you a truth that helped you at that point just as sometimes we do when we introduce other people to our domains our technical domains but also guess what the same is happening with you when you are introduced to something else people are missing things out and then they're oversimplifying things and you think you've understood it and actually it just gave you the really simple version and if we're going talk about a mission sometimes we find it very difficult to define certain things this screen is blank but the moment I put a sign on it it's no longer blank I'm trying to label it helpfully but I'm afraid that that's not the way it works and then somebody says yeah but where did the word blank come from Kevin ah blank came from the French Blanc which means white a blank screen is black oh okay so we've ended up with contradictory meanings that never happens at all in the real world in any domain ever then we also have a priming effect thought yeah that that works with this audience because there we go yeah yeah and I've used the color red too primary are giving us true contextual stuff but if you say that say real and if I'm hearing it in slightly flatter English I hear wrote it's an act of writing I also hear ropes which is an act of learning by repetition repetition that's the thing that you know we don't we don't value don't repeat yourself dry principal but then that also takes me back to the English interpretation same signifier dry rot completely different concept it's about decay now here we have it's very easier and normally you don't end up with these conflicts but I'm laying out the simple ones most of these are far more subtle when speaking about domain there's all these little flows of context that you're not aware of it gets more interesting when people that genuinely do mix disciplines into interdisciplinary subjects have mixed vocabularies trying to find any kind of meaningful boundary it turns out that the creation of bounded context is not an act of discovery sometimes what you're doing is you're creating there's a mix of discovery and creation you're actually synthesizing a language you are cut yeah but the point is you need to make sure that everybody knows your decisions so when we do that so far I've been using words but honestly colors also have meaning red what does it mean red is the color of danger it's also the color of celebration if you go to the Far East okay it's all kinds of things that it signifies blood it's all kinds of stuff that goes on danger do not cross the red man yeah nice bit of graffiti but the notion there is red means stop this is how kids learn it red means stop green means go it also turns out that sometimes you can change the meaning of something just through a small modification and we're not always very good at detecting the sense that what happens is when somebody says something you think I'll that this is a new idea they were talking about it they did the domain expert did something on the whiteboard and you walk away with an understanding because it's they're using some of the same words they used earlier but no they actually mean something slightly different cuz they've just modified them in some slightly different way or they borrowed for camporee from a different domain we hit read though we play with green now if I put red and green together you think traffic lights or test-first programming and I was you were creating a system of vocabulary but then we think it's ubiquitous and we're sharing this are we having a shared experience no I am red green colorblind and my wife and I went to this art installation at the Botanical Gardens in Bristol this summer and we come around and she says can you tell all that that says tell what what says but I'm a technologist I'm not stupid I got out my phone took a photograph and it's just like haha yes the power of technology has allowed me to see that it says is this red no it's gray but the point there is that you've assumed something about the listener you've assumed something about the reader you assumed that the other person and this is clearly a physical thing but the point there is that you're we're talking about your wiring we're talking about your knowledge your knowledge set and sometimes you will not see something you are not allowed to see it by everything that you've already got you have to do hacks like this and this is why we have various techniques to slow us down honestly my wife could tell that in an instant I had to go via a hack so we use techniques to try and understand what is the shape of our software system in the domain that we're dealing with we have all of these techniques and I think we like to think oh they're helping us communicate at the whole point is they're trying to slow you down just thank you nudge and cache your own blind spots and then there are things that not everybody can see i bizarrely enough not only red-green colorblind I'm synesthetic grapheme number in other words I see an association between colors and numbers and this is a fairly standard test as far as I'm concerned this is really obvious I can see the twos leaping out although they did in this test they did use the wrong colors this is the problem with synesthesia your synesthesia and my synesthesia are different yeah for me too is red and five sorry two is green and five is red okay so six just for fun here but there is this notion here of I'm now able to see these various things I make connections that other people don't okay by the fascinating coincidence Kandinsky was also synesthetic which is one of the reasons that informs his art he had different associations in terms of his cross sensory wiring and then we mess people up we say hey look that's green now what color is that yeah this is known as the Stroop effect it's actually on the front of the the original scrum book the Stroop effect is an interference effect it occurs when you get two domains colliding okay you have two sources of knowledge you have two sources of meaning I have a color that gives us one meaning then I have a word that these collide you've seen this in code basis okay first time I ever experienced it was the concept of network what is a network it turns out there's a lot of things it's a it's it's a graph structure it refers to tcp/ip and in the context that we were in it refers to an electricity network that distributes electricity from power stations the word network occurs in most of these cases these are very clearly bounded context so I can actually say oh that's a data structure thing that's a network thing and that is a domain thing but sadly it's not always so easy but also you will find yourself talking at cross-purposes you have to be aware of the interference effect we have words like value great word we keep talking about it yeah scrum talks about it a lot oh yeah you got to you know do stuff by value value hmm okay well people clarify a bit business value okay and they say things like we're gonna prioritize by business value okay that sounds brilliant there's any one thing you can't do it it's actually not possible to prioritize features my business value or other it is but you need a time machine to do it the best you can ever do is prioritize by estimated business value because honestly if you know the business value you are some kind of God you can estimate it an estimate is a probability it is a range I can say we think this is gonna be this but you are not guaranteed that okay so when people are prioritizing by business value they are prioritizing by an estimate that extra word changes the game completely oh but it's just one word Kevin yeah turns out it's a very important word because it gives us a little bit of caution a little bit of humility it makes us ask questions yeah so how do we know hang on slow down a bit and do we reevaluate afterwards mmm if you don't use that word you don't really so this is notion of these words matter and we also drive too hard in terms of it devalues our software developed this is one of my favorite cartoons yes the planet got destroyed but for a beautiful moment time we created a lot of value for shareholders honestly I think there's got to be more to software than this so when we talk about value we also need to be careful of other things so I said I refer to the Maya layman paper and again and loss the software evolution life so he some really good stuff so back in 1980 you came up with this idea this classification s programs P programs and Eve programs this is quite a useful way to understand the the scope and consequence of the thing that you are trying to design as well as trying to find the context consequences an S program program whose function is formally defined by and arrival from a specification sorting algorithms data structures this is the kind of though you know that the basic stuff we're all good with that graphics programs actually even operating systems we can formally define them and you can derive something from it these are I don't say these are relatively easy but if we could only make all of our systems if we can make our complex systems out of these these are testable we can talk about them reasonably then we hit P programs they're a little bit harder P is for a procedure in the sense of I have a procedure to determine acceptability of the solution okay but I cannot derive the program from first principles if I can give you the rules of chess but it turns out that that doesn't help you actually create chess program I can give you a climate simulation but it's all floating-point numbers it's not how the real world works it's all approximate cells ok the world does not work in cells well part from mobile phones but you know it does not the weather does not work in cells it's a much more it's a it's discrete but at a very very fine level so there is this notion of I have an acceptability criteria for this but that's not the one I'm interested in this is the one I'm interested in he programs because this is a lot of what we create programs that mechanize a human or societal activity the program has become a part of the world it models and it is embedded within it and therefore the world the software is part of the world and therefore the world would change the software and the software will change the world in other words it changes as our inputs if you think about social media this is a kind of a key thing now what does this mean what this means is that when I do this remember I said earlier meaning can be derived from action and consequence what do I want to do with something let's understand the meaning of what happened here this is 2011 and this is automated this is a there's an automated system here that well okay the making of a fly there's genetics of animal design now I'm going to say that sounds like a very good book if you're into genetics you can buy it used for $35 new from 1.7 million whoa that's quite that's quite an escalation I mean even in yen that's quite expensive okay this is major anyway this guy went and observed the relationship what was actually happening because notice there's another one down there just over two million what was actually happening is the software had been effectively designed as an S system in other words what you know what we do how do we run our business well what we do is we look and the ratios this is the thing okay the ratios what you've got is somebody has the book their goal is to undercut the lowest other vendor in the market that is our business model we have a rule for it okay that is our rule we've got a little context that is our business and this is our book sadly there is somebody else out there who does not have the book and they have a slightly different model their model is will mark up slightly which will allow us to buy the book for somebody else and then sell it at a markup individually both of these is correct their understanding is beautiful this is the next larger context I was talking about earlier on and what happens when we put these two systems together actually it takes it all the way up to nearly 25 million before somebody realized there might be an issue here yeah you kind of want to say honestly yeah you could throw that one in for free yeah but this is the thing when we are taught we love throwing the work context but yeah those boundaries are really hard to define what is the boundary of an S system it's really simple what is the boundary of an e system it's it's a bit bigger it's got a lot more of the world in it and the world is a very surprising place the meaning of the in other words the meaning and action and consequences these are all related now this you might say oh that loophole was cleared years ago yeah except for the fact that although the British are currently undergoing a large social experiment and which I have to say is not going very well at all it's it's particularly well it's particularly poorly informed and I hope everybody's going to learn something from it but a couple of years ago now the pound is not doing very well but look at that drop bang that's a really short frame of time human traders can't do that human traders can't respond that fast even with amphetamines they can't respond that fast this is the work of machines written to exactly the same kind of careful correct localized bounded knowledge that we saw with the Amazon example meaning is consequence as well so when we talk about full stack development you kind of got to go out a bit bigger so come with that in mind there is a notion here that want to close with some of the terminology that we use is still very programmer or inter this is a rather nice book if you're into if you're into this idea of how do I understand the mains and reasoning this is a book follow on but this is published 95 Michael Jackson yeah you didn't just do thriller this real it's really interesting thoughts in here it's a very dull title but it's it's it's an interesting book because it orders alphabetically a series of thought and ideas about software development but also our misunderstandings and how we reach these misunderstandings and frames for understanding different domains and he talks about domain relationships and sub domains and it introduces problem frames which he elaborated further in 2003 and I find that it even when we start talking domain we are still moving sometimes too fast if you remember the systole diastole the heartbeat it's okay you can go in and out and in and out but sometimes you really need to go and ask honestly what problem are we trying to solve and sometimes that pause you say we are in a hurry yeah we did sure sure we want to create stuff but sometimes you need to call people absolutely what does that mean what is it what does that mean for the business what does that mean in terms of vocabulary what does that mean in terms of a structure of a domain what does that mean for the development so general get the fairly object thing so you know when somebody says don't we don't want to spend time on those just semantics that says just meaning that's the beginning of the conversation thank you very much [Applause] [Music]
Info
Channel: KanDDDinsky
Views: 6,721
Rating: undefined out of 5
Keywords: KanDDDinsky, DDD, Semantics
Id: EbIEtV_31-w
Channel Id: undefined
Length: 65min 2sec (3902 seconds)
Published: Mon Dec 17 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.