A Daily Practice of Empirical Software Design - Kent Beck - DDD Europe 2023

foreign thank you very much when I got the invitation to come speak I said the one thing just don't put me just before drinking please so thank you very much for that the last time I was here was a covid January and uh what an odd thing to go through because it feels like absolutely yesterday and forever ago at the same time so I'm glad you all made it I'm even glad to be honest that I made it and here we are so uh the the uh the quote Matia said about my personal mission it wasn't quite right so I figured I'll start by correcting him because I just I just love giving him needles it's a lot of fun if you haven't done it definitely give it a try um the the mission statement I came up with was this was like 20 years into my career I'm like I've done patterns and junit and test driven development and like what in the world draws these things together because some stuff was very abstract and some stuff was very concrete and Technical and this phrase popped into my head to help Geeks feel safe in the world and uh I thought yeah that about sums it up because sometimes as Geeks we we have tremendous amounts of Leverage and sometimes we're not quite aware of it or we're not we don't know how to take that responsibility so the technical Parts about testing so that you take responsibility for the quality of your work that's a way of feeling safe in the world you kind of know if you're messing around and people are yelling at you and they're upset about it it feels kind of unsafe while doing writing fewer bugs is a way to feel safer but so is having structure around you have how you have conversations with um uh your peers your manager other folks with a different perspective than yours all of that goes into helping you feel safe in the world so um in 2005 I was invited by Stephen Fraser to uh to sit on a panel with Ed Jordan of blessed memory and Larry Constantine um to celebrate the 25th anniversary of the publication of the book structured design how many of you have seen the book structure design okay this is this is easy um so I had it I'd used it as a college textbook so I thought in preparation for this panel I had better read it for the first time so I started reading this 25 year old textbook with its with its examples about paper tape machines and this newfangled higher level languages versus Assembly Language and and yet it became a page Turner for me I'd been doing software development for 20 some years professionally by then and I felt pretty good about my ability to design software but here were Newton's Laws of Motion for software design uh articulated clearly and precisely with careful thought behind them and I thought why don't we have this level of understanding of software design in our in our craft like how did this get lost and so I vowed then that I was going to update that material I was going to present that to the world of software developers because this this is really what we need so that's in 2005. um I made a couple of attempts uh I had a thing I called responsive design which got taken over by the mobile phone people um and I could explain coupling pretty early in that process but I couldn't explain cohesion in a way that didn't leave people going so I um I just kind of let that rest for a while and that's the way I just have a bunch of problems sitting in the back of my head and every once in a while one will raise its hand and then I'll take it out and work on it for a little while and usually don't make any progress I put it back in the back so I started writing essays it was about five years ago I started writing essays around software design I thought okay and I had a two-week period unexpected two-week period before I started a job and I thought well let me just see how much of this book that I want to write I can get written in two weeks so I sat down and it was very productive and uh I I made I made progress but also the first line was a was a doozy for me the first day I sat down I put my fingers on the keyboard and I wrote software design is an exercise in human relationships what software design is an exercise in human relationship no no no no I want to talk about coupling and cohesion and I want to talk about power law distributions and I want to talk about uh Net Present Value versus optionality that's what software design is about all these technical factors uh well if I wrote it it must mean something and the more I thought about what I'd just written the more I realized that is the Crux of the issue that the things that hold us back as technical people are never technical factors we wouldn't be in the position that we're in unless we could learn new techniques unless we could understand technical Concepts what holds back all of the Geeks that like me personally and the Geeks that I've coached over my career it's always human stuff so here's how book writing goes you think okay here's a topic and there's no way I could write a whole book about this topic and you start writing and it gets longer and longer and you realize uh there's there's no way this is fitting into one book so let me just take a quarter of this and that will be the book but there's no way I could write a whole book about just that and then you start writing on it and it expands and expands and you think no way this is fitting into one book and you slice it even finer until you have something that couldn't possibly have a book's worth of material and then that's about a book's worth of material that's that's how I do it anyway I I don't know any other way because every book I've written has been like this so I'll point at the end towards the larger direction that I'm going about relationships but I want to start with the most fundamental relationship in software development and it's one that if you don't get right none of the rest of it's going to be right and that's the relationship with you yourself and what I see over and over again is uh programmers there's they make a big mess they think oh oh you know I'm a bad programmer or I wouldn't have made this mess in the first place and it's really hard to change and the feedback slow and the tests are really slow to run but that's it's just a sign of my commitment to my craft that I power through in spite of all that this is not a healthy relationship with yourself if I touched a touched a nerve there good that's not a healthy relationship with yourself our job is not supposed to be painful sometimes it is but it's not supposed to be and if it is on a regular basis we have a different issue to to talk about so that's that was the slice slice slice this is the topic of this book tidy first question mark that I'll be taking material from today and um the the book is centered around this question that comes up 10 times a day as a programmer I need to change this code it's ugly the structure of the code makes it harder to change do I tidy first and there's two dogmatic wrong answers one is always and uh this is one of the things that motivated me to write a software design book is there's a couple of software design books out there which just say well if the code's messy you clean it up that's you just you know somebody's waiting for some feature well that's just too bad you are the high priest or Priestess of this code and uh if they want to commune with the deities of computing they're just going to have to go through you and I well that's not a that's not a healthy relationship but then there's the other one which is this self-immolative never I'm never gonna tidy this code up I deserve to at a modified code like this this is I'm payment for my sins I must deserve this or it wouldn't be like this even if I didn't make these mistakes someone else my one of my brothers and sisters did make these mistakes and I have to pay for their pain as well and that's also not a healthy relationship with your code or with yourself and uh this is the international symbol for trade-off did you know that uh so the answer of course should I tidy first is it depends and the cool thing is when I started describing even at this micro scale of software design when I started listing all the factors that go into whether to tidy first I got to pull in all of that technical stuff all of those Concepts that I wanted a little bit of them not the really cool juicy bits but a little bit of them I could pull them in and use that as an explanation for okay you're faced with this question ugly code tidy first yes or no oh well now I have to think about coupling in cohesion and power laws and Net Present Value versus optionality and so on and so forth so I get to talk about a little bit of all of software design in a context that everybody uh encounters on a daily basis as a developer and that will be the foundation what I expect to be a series of books which I'll outline when we get to the end now the way I do these presentations is I pray that I've here we go are we up we're up I don't know what those lines are but they look interesting um so uh how many of you were in vlad's coupling presentation okay so uh if there's a if I go too fast please ask a question uh if you have a question I guarantee that 20 other people in here also have the question and don't have the uh whatever to just up and ask it so you'll be doing other people a favor if I go too quickly through this please let me know I have I have some uh things to add to what Vlad said let me put it that way um so the first thing that I have to to to add is um there's a specific reason for doing software design uh which is the one that we're getting paid for now everything doesn't reduce to Euros but if we forget that things also reduce to euros we're gonna have a bad time so uh Vlad was talking about pain we have some pain and software design let's just address this pain and I I don't uh that's not how I see it I think it's much more specific than that and this is straight out of structure design I call what follows Constantine's equivalence so Larry Constantine was one of the two people who wrote the book structure design and the way they wrote it was by examining a bunch of programs at IBM and looking at the ones that tended to be cheap to change versus the ones that were expensive to change and they said what is common between all of these very different programs that are cheap to change what is common to all these different programs that are expensive to change and so Larry's observation is that the cost of software works the cost of software the first observation is that the cost of software is approximately equal to the cost of change that is maybe we we think about oh I'm going to develop this software and that's what's expensive and so we should make that cost less but that initial period before you go into production is Irrelevant in the time scale of the program either nobody's going to use it and it kind of doesn't matter or people are going to use it and will spend ten a hundred a thousand times as many euros changing the software as we ever did in that initial phase so so any technique that focuses on that initial phase is just looking at the wrong thing to optimize because it's such a small fraction of the total cost of the software so the second observation in Constantine's equivalent is that the cost of change not all changes are the same size some changes that you make are very expensive and some changes are cheap and if you add up the cost of the few really expensive changes and you compare that to the sum of the cost of all the cheap changes those few really expensive changes dominate the equation so we can for purposes of optimizing costs we can ignore the cost of those little changes people come to you they say can I have a widget that does this you make a widget that does that they say can I have a widget that does this you make a widget that does that uh in the overall picture those don't matter compared to the when they say can I have a widget that does this and you say oh currently the model has one email per customer and that's actually spread all over the place that assumption and we're gonna have to go away for nine months and get ready to make that change and then the change is going to be easy that those expensive changes those things that break fundamental assumptions in the system those are the ones that dominate the cost of software and then the third part of Constantine's equivalent is that the why are those big changes expensive it's because I change this which means I have to change this and this which means I have to change these four things which means which means so the cost of the big changes is approximately equal to this this virality this I change this which means I have to change those things too and the word that they use to describe that transmission of change from one element to another element was coupling now coupling as a word there was a very precise definition in structure design if you read it I don't remember what page it's on because I have better things to do but it's there black and white that's the definition of coupling says if I change this I have to change that those two things are coupled and it's that transmission of of change that makes those expensive changes expensive so I can put all of these together and say that the cost of software you see where this is going it's approximately equal to the coupling foreign and that's what's being addressed with software design the reason we design software is so that we can change it and that we can change it at reasonable cost if we never had to change the functionality of the software the computer doesn't care if the variables are named in some rational way or x y and z makes no difference to the computer if we don't have to change it nobody ever touches that code nobody cares about the structure of it is it one gigantic function or is it a million tiny little objects the structure just doesn't matter until the moment that you want to change how it behaves now turns out that coupling happens all the time for all kinds of reasons and when you dig into it there's there's a whole um taxonomy of forms of coupling and their cost and so on but um one thing about it is as software designers one of the things we can do is reduce coupling but that also whoops I want didn't mean to go backwards there we go as designers when we spend time energy money on reducing coupling that costs two and now we're back into one of these we have a trade-off space where we could try to decouple the here we have the cost of coupling and if we've driven way too far up here where everything we touch breaks something in some random distant place that's very expensive but also decoupling costs and if we try to decouple all the things in fact you can't decouple everything and if you did decouple things and I'll explain how how this goes in a second if you decoupled for the kind of changes that you have today and you start making different kind of changes tomorrow you're going to discover all new forms of coupling that you didn't suspect were there so we can spend way too much on decoupling we can spend way too much on coupling and what we're trying to do is find that balance in the Middle where we're spending a reasonable amount on both of those factors so this is about cost Management in software development software design is a way to control the costs of continued development of software that's that's what we're here for questions so far somebody warned me that there are people lurking up there and it was a little bit disconcerting I hadn't realized it would be this disconcerting okay so let's get us a new page how do we do a new page um I'm just going to erase everything how about that you can't stop me computer okay so so coupling what is what is coupling uh has come to mean two things depend on each other they they are connected in some way that's not the original definition of coupling and it's fine to talk about which elements in software are dependent on each other in some kind of way but there's this very specific relationship between elements that is what coupling originally meant and that's what that's the definition that I'm going to use so we have these elements in in software so you have a bunch of functions or you have a bunch of services or you have a bunch of repos or whatever they're elements and they're related to each other and uh two elements E1 and E2 are coupled E1 E2 with respect to a specific change Delta just doesn't look like a Delta that's defined as if I change E1 that means I have to change E2 also this is already a little different than most of the definitions I had seen of coupling but going back to the original this is this is the one that's in structured design so you can have two elements and they can be coupled with respect to certain changes and decoupled with respect to others so if I have a function that calls another function they are coupled with respect to the name of the called function if I want to change the name of the called function I have to go change the caller at the same time so those two things are coupled with respect to name changes but they aren't coupled with respect to formatting changes if I if I change from spaces to tabs or tabs to spaces whichever one pisses you off uh in the called function the calling function can blindly ignore that so they're not coupled with respect to those specific changes this is why a static analysis of coupling makes no sense I can't take the code crank it through something and it tells me I'm way coupled or I'm not way couple because I have to know what changes I'm making so if I uh if I have a tax calculation and I get new tax regulations once a year and I have to go change the tax calculator uh that that element the tax calculator is coupled with respect to changes coming in from the outside but there's a lot of other changes of the system that it won't be coupled to now coupling can be uh subtle and can be very expensive so one of my favorite examples of coupling this comes from Facebook is there were there were two services that happened to sit in the same physical rack so you got a rack a bunch of servers in them and you got us network switch sitting on the top of the rack and one of the services changed its backup procedure from doing little incremental backups once a day to doing once a week big backups well the little incremental backups weren't any problem the network switch had plenty of bandwidth but when they started doing these big backups once a week the other service would fail and it would fail because those two Services were coupled with respect to changes to the backup procedure because the network switch had a limited amount of bandwidth those teams didn't even know each other existed the system was coupled with respect to that particular change in ways that nobody anticipated and if you go and look at I don't know if you one time I was sitting at Powell's Bookstore in Portland and if you haven't been to Portland and you do go go to Powell's Books because it's awesome uh and I because and the reason it's awesome is you pull out random books you would never look at except you're in a bookstore that's three stories tall and it's I pulled out this book which was uh every commercial Aviation every fatal commercial aviation accident in history and what was learned from it it was a little gruesome I will give you that but it was also fascinating because it would say all right well you know here was this thing and there was some emergency and the pilots flipped this switch you know which said crash into the ground instead of flipping the other switch switch which said uh you know save everyone's life maybe we should have those switches further apart and I thought oh that's that that's that same kind of and same kind of thing there are there are things that are connected together in ways that you just you can't anticipate and when you're operating large systems you're going to discover coupling all the time and you're going to be back in this space where you have to say uh am I going to decouple this uh or am I going to not decouple this and have to explain this disaster again in a year you know and that's a reasonable trade-off to think about um so this is the original definition of coupling if I change this two elements with respect to a change if I change this I also have to change that and one of the other interesting nuances of coupling that I didn't suspect at first was your tools have a part to play in weather elements are coupled so if I have uh Reef automated refactorings and I want to change the name of a function that's called a thousand places but that's one change I bring up the change the name of this function dialog in Eclipse it was a beautiful wow don't get me started on refactoring you're not getting me started on refactoring I'm getting me started on refactoring I understand that but I figured I'd pick on you just for a second because I can make that change in a single Atomic activity then those functions aren't coupled with respect to the name of the called function because it doesn't matter do I call it 10 one time ten times a hundred a thousand a million I change the name once it gets changed everywhere I'm guaranteed that there won't be it I won't accidentally break any of the semantics and we're finished so it's not just the software design that dictates the coupling but the tooling that you use also changes what is coupled and what is not another reason you can't just take the software run it through the coupling detection machine and come out with the 4.7 and have that mean anything oh and and so what I want to talk about next so another thread one of one of the things about ideas is it's always the combination of stuff that comes in and one of the ideas that I've been fascinated with wow I don't even remember probably 95 was uh were these power law distributions where if you uh if you look at the number of collars of a function if we make a histogram and we say how many people call a function and how many functions are called exactly once we get a whole bunch and then it if how many functions are called twice we get kind of half that many are called twice and how many are called four times and it's like half that many and and and if we plot that on a linear a linear histogram it goes way way up for the small number of colors and then the the most called function is going to be called a ridiculous number of times and I thought well that can't be right the same is true of say cyclomatic complexity you're going to have a whole bunch of functions of cyclomatic complexity one and you're going to have one function that's cyclomatic complexity like 600. and you look at that you think well you know what idiot wrote that it turns out you did and it's not your fault kinda not your fault because if you how far how deep do I want to go into this I get so excited about this if you if you change the axes of this log and I've got some stuff published about this and feel free to ask me about it more I promise it's only going to last one more minute if you change the axes of that that graph to logarithmic one ten a hundred thousand million or ten thousand hundred thousand million and the same you get an absolutely straight line how does that happen well coupling is exactly one of these phenomenon and it's it happens the same way that avalanches happen because you have one snowflake that falls over and it has some chance of knocking two snowflakes over and those snowflakes knock more snowflakes over I mean if you could get to that first one and tell it to just hold still for a second you'd be okay but but that's not how nature works hurricanes same kind of thing the bigger the hurricane gets the more energy it Gathers coupling is the same kind of way you're going to have some areas with lots of coupling and some areas with with very little coupling and as designers that's what we're doing we're navigating this bumpy space we're trying to find the ones that have more coupling that we than we would like and we trying to reduce that coupling okay so I said coupling is potentially everywhere if we took every element of the system imagine the system you work on every single function every single class every single process every single service and we listed them and started making X's of if I change this I'm also going to have to change that you can't hold all that in your head so the second observation that Larry and Ed made was that the inverse of coupling is also valuable not the inverse of coupling the the span of coupling is important to look at and they coined the name cohesion to talk about that and again cohesion is one of those words that has just kind of is this stuff go together well then it's cohesive do we does this class do one thing well yeah I think it this was a single responsibility principle you know which is like a stick that you use to hit other people with my it's it's kind of it's got a big knob on the end and and it's an argument right does this does this class do one thing well yes what well this and that is it cohesive yes I would say it's cohesive there's a technical definition in structure design of what cohesion means and now I can I think explain why it matters that that was the part that took me 2005 till about 2020 maybe so only 15 years better than average for me I'm just really stubborn that's that's it so what is what is cohesion technically cohesion and Element e is cohesive if it's sub elements are coupled e one dot dot dot e n that's all it means now you look at that and you think isn't that bad don't you not want to have the coupling of your sub elements wouldn't that be better like more cohesion is better right yes but more coupling is bad right yes but if cohesion is coupling that's why I don't feel bad it took me 15 years and the answer to that is it's a compared it's one of these compared to what one of the most powerful questions you can ask in history is compared to what you know when I coach people someone will come to me and I'm just the worst programmer ever and I say well compared to what and then we're making some progress sometimes they're right but that's a separate issue then then we kind of shift gears in the conversation okay so here I've here I've got an element and I want to know if it's cohesive so it has some sub elements say this is a file why are we still putting source code and files could somebody explain never mind it bugs me but anyway okay so these sub elements are all coupled if I change one of them I have a file with three functions and if I change one of them I have to change the other ones too okay uh well isn't that bad well compared to what what if we take this and we put it in a different file and now we have coupling that crosses these file boundaries that's definitely worse because now if we want to know I want to make this change can I make can I just what do I need to change now I have to go examine two files the files aren't in the same directory can anybody explain why we put source code in direct never mind we have to go examine more directories to find everything so the more spread out the coupling is the more expensive it gets the less likely likely we are to see it oh here's a great way to find coupling in your code that requires a very sophisticated technical answer called search you say um uh be sure you search for the the phrase be sure because you'll see comments like if you change this function be sure to also that's coupling at a distance and you can reduce the cost of changing that code by reducing the distance so in this this case here if I move this function into the same directory as the other functions it's coupled to I've reduced the cost of making changes to it I haven't gotten rid of any coupling but the coupling that's there is cheaper and that's what cohesion is an element is cohesive if the sub elements are coupled to each other now if you follow that and you increase the cohesion of your elements you're going to find yourself breaking your system into smaller and smaller chunks because otherwise if you have big chunks of stuff there'll be parts that aren't coupled to each other and you can find someplace else to put that which brings me to one of the the challenging aspects of writing about software design is there are two audiences for writing about software design there are lumpers and splitters and lumpers want to see everything all in one place and Splitters want to pull stuff apart in the little pieces so they can understand the pieces separately and you'll know a code base that has all lumpers because you'll have great big functions in great big uh files and great big directories and not very many of them and if you see one that's all Splitters you'll have little bits and pieces and no computation ever seems to take place anywhere and yet the system runs so what's up about that and then you you can also tell the difference when you have some lumpers and some Splitters because there's there's blood and broken glass everywhere and all right maybe it's not quite that bad where you are but uh um okay so that's coupling and cohesion those are the technical definite I'm not going to say these are the definitions these are the original definitions of coupling and cohesion and I don't care if we call them A and B or black and blort or whatever but though these specific properties of a design help Drive decisions that are going to reduce the cost of the of software development over time so I want to keep those original definitions in mind all the other these things are related to those things or depend on or whatever those are fine but I would like to use different words for those so I'm going to just say coupling and cohesion because it's my book and then we'll see what happens after that okay [Music] um next is ah so so I'm writing this book and I'm trying to understand uh uh the role the place the moment of software design in a development process and where I came to was here's the basic Loop of of software development you get an idea for what the software should do and then you change its Behavior to do that yeah and then as soon as you change the behavior of the software to do that then you get more ideas oh we could also do this or that or this thing which is why okay short rant the waterfall I don't know if you knew this is back Italian has great words for this what I'm feeling right now here's the thing there was about 10 15 years where people would still do water Folly stuff and they'd apologize for it and I thought that was progress well yeah we we spent six months carefully surveying the domain yeah we know we know we now no no no no of course you begin with a careful and thorough Nerf Nerf Nerf Nerf its analysis it's based on speculation and the moment the software goes into production all of those decisions are going to change why not put the software into production now it's the same reality we all had to deal with but now people are no longer apologizing for operating in a patently ineffective way thank you for being here for for this okay so here's the basic Loop you have some ideas you need to change the behavior that gives you more ideas and you get into this Loop and every change that you make to the behavior of the system back to economics is either going to increase revenue or it's going to reduce costs if it's not then why are you changing the behavior even if it's an expected value calculation you're like well I think people will use this and so we'll make more money that's fine but there's immediate economic value out of changes to the behavior of the system but as designers we know this is not the whole picture as is walking over here walking over Canal I was looking at Ducks and the Ducks are serenely floating along and then I noticed Down Under the duck I could see under the water and the feet are just paddling furiously that is software design and then I noticed some other stuff happening under the water which is also software design but sorry so the structure of the system radically affects the cost of changes to the behavior of the system so sometimes we'll get an idea and we'll think Hmm before I just go and Implement that and I change this code that's scattered all over 50 different files maybe I'll cohere that's the verb form of increasing the cohesion I'll cohere the the software first and then I can make the relatively easy change and this is the this I came up with this phrase with a student for every hard change make the change easy notice this may be hard then make the easy change and this is addressing exactly this masochistic self-flagellant no you know if I have to make some change and it's really hard it's one of my options is to go and make it easy to make that change but making that change easy can be hard so you have to reply apply this recursively in kind of a zipper [Music] that I'd have to change and then to do that and then I'd need to build a tool for that and then zip that's that's the story and I'm sticking to it so this flow from idea to structure change to behavior change is exactly this tidy first flow that's the moment where you say well I could I could change the behavior by going and editing 50 files or I could change the structure so that I only have to change one file and to finish the the picture uh sometimes you just get sick of it and you just like I've edited this file 85 times and I always get it wrong and so I'm just gonna go change the structure this is a little more speculative and can be dangerous and here's part of the magic of software is that sometimes the structure of the system suggests ideas you're having Friday beers with a colleague and they say oh I wish we could just build blah blah blah and you're like that sounds easy I know as somebody who lives inside the code that that would be easy to do so let's just try it and you can have an experiment that's cheap because you happen to understand the structure so part of the problem with this picture is that Behavior changes are very visible the they're the they're things that go on the road map they're things that have uh obvious economic impact and the things the changes that you make to structure are uh uh one step removed from that they change the optionality of the system they make certain things easier changing the structure makes certain things cheaper or easier or safer to change in the behavior world but optionality is harder to account for than than actual Revenue and so I think everybody who's involved in software gets the feeling that we under invest in structure and we over invest in Behavior which taking over a span of time means we get fewer Behavior changes than we could have gotten if we'd balanced the investment both ways so uh concrete takeaway from tidy first is to separate your changes of the behavior from your changes to the structure changes to behavior tend to be irreversible if we change the numbers that we report to the tax Authority and we get it wrong that's an expensive mistake if I extract a helper function and you don't like it and you inline it is easily reversible if so reviewing Behavior changes requires more understanding and more care I want to see new test cases for Behavior changes and I want to understand that they cover the situations that will occur in production Behavior changes I can pretty much just stamp and so a simple thing that you could do even just for yourself is start labeling them SNB or B and S but that's a different just start labeling your changes SMB and if you get into that moment where you're changing the behavior changing the behavior you're like oh and this variable is named the wrong thing okay either do it afterwards or throw away the changes you made change the name of the variable and then make the changes either one is fine as long as the two are separated because the treatment of those changes can be very very different so um I'm going to give you the three minute version of this which was going to take 20 minutes thing I noticed last week I was working with some very good programmers who were maybe five years in four or five years in and what I noticed was they were all solving problems that were too hard how's that work well when you're a beginner programmer you don't know how to deal with complexity and then you learn some little trick say you learn some skill and now you can deal with a little more complexity so you grab the next bigger problem in complexity and then you try to do that and you kind of fumble but you learn the skill and then you can grab some more complexity and that cycle works for four or five years just fine people get more and more skills to handle more and more complexity at once eventually though your brain you hit the limits of your brain and now the learning strategy switches and what I noticed about the people I was working with last week were they they were either almost ready to make that switch or they were not ready to make that switch and the switch is when experts approach a problem they they don't bring their wizard-like powers to it the first thing they do is try and separate it up into smaller problems which can be addressed with ordinary levels of skill now that decomposition can take a lot of creativity and a lot of skill the the this is a good example this separation between behavior and structure a pretty good programmer will know to clean stuff up as they're implementing things and they'll mush it all together but eventually you got too many changes going at once and you get confused and then that skill of saying well I'm going to change the structure a little bit then I'll change the behavior a little bit then I'll change the structure and I'm going to keep those very separate that becomes the skill that's required to take the the next level up of of complexity so this separation between behavior and structure changes is an example of this complexity partitioning DDD has a powerful set of tools for complexity partitioning this coming up with bounded context is exactly a partition inside of this I have to have a certain level of Knowledge from the outside of it I can ignore most of the knowledge that's inside of that and then every once in a while the boundaries are going to be all wrong and then you have to switch it up but that's a learning opportunity so there we go so uh what I'd what I did for the people I was working with and what I'd recommend to you is become aware of those moments when you're trying to solve a hard problem and see if you can break it into solving easier problems that compose the test driven development is another one of these complexity partitioning strategies where I don't know how to implement it but of course I can write a test for it so write the test for it oh well then implementing it's easy I just have to make the test pass okay but if you put the two together you're doing something that would have been really hard to do if you try to do them together another example is this make it run make it right where programmers want clean code that works and they think that means they have to write clean code that works one doesn't you can write that works and then do the clean code part separately and then you have two brain sized problems instead of having one overwhelming problem so to conclude tidy first is about this relationship with yourself in this picture thank you to whoever's timer that was this is so nice such a helpful crowd tidy first is becoming aware of when you have an opportunity to change structure that helps you change the behavior and take him into account all of the variables all of these technical influences for answering that question that's a way of healing your relationship with yourself when you've done that you are better prepared to build and maintain relationships with other Geeks the other people on your team where your software design decisions are affecting me you change some apis that I call if you say you know take it or leave it we're going to have issues but if you realize that this is a relationship problem and you just caused me work and it's your responsibility to bring our relationship back into balance then we'll be able to continue developing together that's the next level up and the that's the next book and then the last the last uh level of it is maintaining those relationships with the the business sponsors the users the managers product design all the other people with very different perspectives on software development and I believe that software design also has a role to play in that but first ask yourself is this a case where I can help myself by tidying first thank you all so much for your time and attention [Applause]

Channel: Domain-Driven Design Europe

Views: 29,456

Keywords: ddd, dddeu, ddd europe, domain-driven design, software, software architecture, cqrs, event sourcing, modelling, microservices, messaging, software design, design patterns, sociotechnical

Id: yBEcq23OgB4

Length: 59min 14sec (3554 seconds)

Published: Wed Oct 18 2023