Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020

[Music] thank you very much it's very bright up here in case uh you didn't uh pick that up right away i'm i'm so glad to be here uh i have this is my first ddd conference of any sort i was reflecting on my uh i sort of my world and the ddd world sort of bump into each other but uh but don't really overlap a whole lot i was thinking about when i first heard about ddd um i had actually worked with eric uh in 2000 um and i'm not going to ask who here was born in 2000 because it'd be too depressing um and we we worked on a project that also included some other uh notables this was the the whole dot-com era when we were all going to get rich didn't didn't happen um and uh it was a interesting domain the domain was uh planning for retail purchasing which it's one of those things where you say how many times have i said this as a programmer how complicated can that be and the answer is always is really complicated but uh the team and and eric included really dug into what it meant to do a better job of retail purchasing and then the dot com crash happened and everybody scattered to the winds but that was the first introduction that i had to it and then when the book came out i read it and thought hmm interesting ideas it's a little different than my approach to it but i'll be informed by this in the future but i've never been a follower or an applier of ddd like straight out of the book so it was interesting to get for me to get this invitation and have a chance to come and see what had happened to the community and the community of practice over over the past 20 years extreme programming uh has its own community practice it's also grown and adapted um i had a conversation with eric a couple of days ago about our different approaches to our community so he has stayed very involved i've kind of pulled back and done other things and uh so it's not often you get a chance to talk to somebody in in that similar kind of situation having started something having seen a big community grow and well how do you manage that as somebody who likes to start stuff and isn't so good at finishing things that would be me so um when i got the invitation to come and speak i thought what in the world am i going to uh to talk to you folks about i thought i know what i'm gonna do i'm gonna have a title that's so generic that i could fit absolutely anything into it and then i'll just go talk to people and i'll see what it is i think i need to say given the people that i've talked to and so that's what i'll be doing um i don't i can't you'll see in a second i hand draw my slides i don't have prepared slides so i have an opportunity to kind of come up with things in the moment which i really appreciate and uh i hope that you will too and and if you don't you'll probably tell me about it so that's okay so um first thing i wanted to share was uh it's not about programming at all it's about public speaking somebody asked me in the elevator this morning are you getting nervous about giving your keynote and i said well i wasn't until you asked me so no that's not what i said it's not true but it would be a really good response so no what i said was uh um no not really but there's actually more to this story there's a reason that i don't get nervous when i speak when i was in college the american school system is weird like everything american but one of the things about it is you don't get stuck in a track i think there are educational systems where very early you decide what you're going to study and that's the one thing that you study and you stay focused on it in america is a little loosey-goosey so my first year i was a computer science student the second year i was a music student because of course and then i missed programming so then i was a computer science student and then i was a music student and i did my senior recital then i did my master's in computer science and i just ended on the wrong year so here i am speaking at a computer conference so one of the things about music though is you have to deal with performance anxiety everybody feels some anxiety around performance and uh there's a beautiful book called the soprano on her head about dealing with performance anxiety and the the story from the title is a there was a soprano had a beautiful voice had so much anxiety she just couldn't sing anymore so the teacher had her stand on her head and sing and it was just beautiful again like all of the anxiety went away of course she couldn't do that on stage because that would really look weird but it was it was it's like a an example like no you you can still sing that's the as a musician you're like maybe my fingers won't work this time or something like that they usually do so that's okay but there was an exercise in that book and it went like this it said imagine yourself going up on stage and performing now take an inventory of your physical sensations at that moment your stomach's queasy your palms are sweaty your breathing is up in your chest and shallow okay so that's what that's what nervousness feels like right now imagine yourself christmas morning as a kid you're about to go in and open the presents imagine that moment and take an inventory of your physical sensations at that moment your palms are sweaty your stomach's a little queasy you're breathing shallow high up in your chest and you're excited so the same sensations you say well i'm feeling nervous that tag of nervousness applied to those sensations is a choice that you make and you could say i'm excited at that moment now then i remembered the first time we ever uh ward cunningham and i ever presented about patterns 1987 we're in a workshop um we had done our first experiments with patterns things had gone exceedingly well we had a little write-up and i was gonna get up and present and around the table were all the heavy hitters of the day grady booch was there a very young jeanette wing was there adele goldberg and i was just getting nervous as i'll get out my my time slot was in the afternoon of course so i had all day and i remember about mid-morning i was just getting exhausted because i was i was feeling so so nervous and then i remembered this book and i said to myself i am really excited and the the negative experience of all of those physical sensations just went away i and it was just a change of my frame so in answer to the elevator question are you nervous no i'm excited i feel some of the same sensations as when i feel nervous but i just choose to frame them as wow i've got something to talk to you about that i really want to talk to you about so now if you don't care at all about the technical content i've just given you something that you can take away and use regardless of of what else it is that you do you're welcome okay on to the geeky stuff so here's what i noticed most about the conversations that i've had over the last couple of days there are a lot of people talking about coupling and cohesion yeah important concepts really the foundation of the work we do as software designers but the other thing i noticed is everybody means something a little bit different when they say coupling and cohesion sometimes it's a big concept comes out of a small concept it goes in slightly different directions maybe 10 years ago i was on a panel celebrating the 30th anniversary of the publication of structured design the green book how many people have read structured design okay cool the rest of you are in for a treat this is a book that ed jordan uh a blessed memory and larry constantine had written describing their experience with a whole range of software written in the early days of programming they what they did was they looked at the software and they said uh of the programs that were hard to change what features do they have in common and of the programs that were easy to change what features did they have in common can we see any patterns in how the software is constructed and the answer was yes and they came up with these concepts coupling and cohesion just to describe the common properties of programs that are cheap to change now back in the early early days the thought was that we would build programs and then just run them like uh manufacturing you build a car yeah maybe there's a little bit of maintenance but you don't like rebuild the car now it turned out the software wasn't like that we fought against that for a long time you know people would say i remember the breathless we spend 70 percent of our development budget on maintenance isn't that awful doesn't that show what a horrible job we're doing and that's true if you had a car and you spent seventy percent thirty percent buying the car and seventy percent maintaining it you would not be a very good car but the thing about software is the very uh presence of the software as soon as the software comes into being the needs that it addresses change so by its very nature software changes itself you know you people see some feature and they say oh i'd like this other feature too they would never have thought of that until they'd seen that first feature that was a big surprise so these concepts of coupling and cohesion were laid out very precisely in the green book the structured design book now i had had structured design as a textbook when i was in college and so when i went to sit on this panel i realized that i should actually read the green book for the first time because you know it was a college text it's not like i read it so i read it and i was just i was so excited i mean there's some weird stuff in there like a very thoughtful discussion about assembly language versus higher level languages you know which was an open question at that time and and something about punched cards and paper tape and i'm like so that part aged quickly but the part that didn't age at all was were these concepts of coupling and cohesion and the definitions are very precise in that book since then we've come up with other uses for those words so what i'd like to do is go back to those original definitions and say here's a meaning here's a concept of coupling in this very particular way i'm talking about it and and you can apply whatever word you want to to to it but that concept is really valuable and important so we should separate that i think this is the message i bring to you separate that concept from other concepts that we may also apply the word coupling to we should probably find other words for those things because this thing i'm talking about is very important and worth focusing on as a designer so uh first software is built out of elements and when i say element i mean things at all different scales so variables or elements and statements or elements and expressions or elements and functions and classes and modules and services all these things are elements repositories are elements so when i say i have two elements a and b and i say that they're coupled what does that mean so it means that if i change a i also have to change b so here's the in in something that looks a little more like a a mathematical notation a and b are coupled with respect to a particular change so coupling is always with respect to a particular change if changing a implies changing b that's the original definition of coupling so if if i have two services and one service calls the other those services are not coupled by this definition they have some relationship and we should have a word for that relationship but it's not coupling unless changing one service means that we have to change the other service too in order for the system to stay in a in a working state so an example that came up yesterday in conversation was here i have a service it takes in some some parameters and there's a parameter a and a parameter b and i want to change the name of b to c but i pass this to another service that expects parameters a and b and connects it i think the number that was quoted to me was seven this thing is passed through seven layers of services all of which expect the names to be sorry a and b so these services are coupled with respect to name changes of the parameters i can i can go inside of a service i can go inside this service and make all the changes i want as long as i don't change the name of the parameters neither the other services have to change so uh for those kind of changes there the services aren't coupled but for purposes of of these names that they are coupled and the complaint was wow if i have to change one then i have to change all of them and my best bet is then i have to deploy all the services at exactly the same time and make sure there aren't any requests in flight so like it and you you have a distributed monolith which is worse than a monolith um so how would you how would you go about making this kind of change so in my kind of design world i use a pattern called parallel where you have briefly you have two implementations of the same thing so if i want to change b to c i'm going to add a c here and make sure that always contains the same value as b now i can deploy this nobody else is looking for c so they don't care then i can add c here and now i can start using c because i know it has exactly the same thing as b and as soon as i'm done with that as soon as i know that this service doesn't use b anymore to read it i can stop passing it then i can make this change too so i don't actually have to deploy all of these changes at exactly the same time by going through a little bit of this uh making things worse and then making them better i have a chance to uh decouple the ch changes i can stage the the changes so that's a trick that always seems to bother a lot of people because it makes things worse i have duplication i have more duplication and then it makes things better but there is another life lesson for you rule number one is things always get worse before they get better and rule number two is you can you can do it that's uh so i thought this was going to be a programming talk with some little life lessons and it may be the other way around by the time we're done but we got a half an hour so let's see what happens okay so that's coupling coupling means i have these two elements if i change this one i have to change that one too why is that important it's important because uh cost the cost of software is roughly equivalent to the cost of change that's that observation about we spend most of the money in software development on maintenance which is just in the xp world we took this entirely all the way and said instead of spending 70 on maintenance what if we spent 99 on maintenance that seems like a good number we'll just get it in production and then build it up from there and then we're mostly making changes but the cost of change all changes don't cost the same amount the cost of change is approximately equal and i'll explain why in just a second to the cost of big changes and what do i mean by big changes if you made a histogram of the cost of changes this is the count of the number of changes that you make and this is the cost that's supposed to be a euro sign the minus of handwriting slides is my my drawing handwriting sucks so oh well so if we make a histogram what it's going to look like is this we're going to have lots and lots of little changes that are cheap and we're going to have a few changes that are really expensive what are those what's the nature of those changes here's where coupling as defined just here is really helpful what makes changes really expensive is not just the change it's i change this so i have to change those so i have to change those so i have to change those it's this cascading effect now if you looked at complexity theory you're going to recognize a power law distribution here and it's the exact same mechanism as causes avalanches and hurricanes you know most avalanches is is just one snowflake falls over and that's it and nothing else happens but there's a non-zero chance that one snowflake falling over is going to cause two more snowflakes to fall over and each of those has a non-zero chance of causing two more and more and more so if you make a histogram of the size of avalanches most of them are just going to be one snowflake falling over and that's that and there's a bajillion of those happening all the time and you don't really notice but you notice the one that comes sweeping through the village and wipes everything off the map and those happen every once in a while the more changes the more extreme both of the ends of this are going to be so when we have way more changes we're going to have many many more small changes and the most expensive change is going to be much much more expensive in software what conducts the cost of of a change is exactly coupling if a and b are coupled then when i change a i have to change b and if b is coupled to c and d then i'm going to have to change c and d and and and and and thing about power law distributions is a big percentage of the cost is in this tail even though this is a small number of changes in the absolute number the cost of that compared to the cost of all the rest of it that tail is really expensive so coupling is important because the less coupled your system is the less likely the changes are to propagate the less extreme the cost of these most expensive changes is the longer you can last uh continuing to change the software so that's where that definition of coupling gets us it's important because decoupling things reduces the cost of making changes over time a coupling can be uh can be quite subtle uh i was at facebook for seven years if you feel the need to blame me for like the destruction of democracy go right ahead um whoops [Applause] i remember once there were two services now you might think well coupling that's like if this function calls that function and they're coupled with respect to the parameters to the functions that okay that's fine but if i have two services that have nothing in common then they're not coupled right well no there's a non-zero chance that any change you make is going to break something somewhere else and the more complicated the system the more likely that you're going to have these crazy action at a distance effects so there were two services they happened to be deployed on the same physical rack so each uh computer has its own network interface card they all flow up to a switch on the top and network switch on the top of the rack so one of the services changed its backup procedures to do all the backups at once once a week and that saturated that switch that rack switch the other service suddenly couldn't communicate to the rest of the world and it failed but so these two services are coupled with respect to changes to the backup procedures who knew right everything can be coupled to everything else and the bigger and more complicated the system the more likely you are to find these kind of weird action at a distance couplings and then what do you do so as a designer there are some principles that you can use that help to reduce that kind of coupling the principles at the very finest grain at the level of code are the sorts of things that i wrote about in the small talk best practice patterns and then the java version of that the implementation patterns book which is just here's some habits that expert programmers use so that they communicate to other programmers the most expensive coupling isn't the coupling that you that you actually see it's the couplings that you don't see where like this these two services sharing a rack switch that's coupling nobody even knew existed until there was a disaster so expert programmers just have some habits at the at the lowest layer like not using global state is a really simple one just be explicit about the data that goes in and data that comes out and if you're explicit about the as my father would call them the gosintas and the gazotas then if you want to analyze the situation you can see okay here's what goes in here's what comes out i'm not making any changes to global state that's just a habit if you can follow that habit it'll be easier for you to identify coupling so so the there's a there's an inverse of coupling so this other word cohesion that people talk about yeah and it's another word that has in the original definition has a very precise definition but that's not a definition that seems to have carried out over time so here's the original definition of cohesion if here i have an element and it has sub elements this element e is cohesive to the degree that its sub elements are coupled that means is if i have to change one of these i'm going to have to change all the others at the same time that makes e cohesive now i read this in the green book i'm like well isn't that bad to have all of your sub elements coupled to each other and as always the answer is compared to what if let's say we have a another situation i think of these things kind of an abstract way let's say i have these two elements are coupled but these others other two aren't and i need to go make a change to e so i so i make a change to this element so i make a change to that element but i'm gonna have to at least look at these others let's say this is four functions in a file and i if i change one if i change the writer i have to change the reader two and then there's some other functions and i don't have to touch those now i might say well that's good that i only have to look at part of this file in order to make the changes but there's an even better solution which is to have this element be broken into two where these things are coupled with respect to the change and i don't have to even think about this part now this uh what e sub 1 this is more cohesive than e was originally because if i change one of these i'm always going to have to change the other and here's the beauty of cohesion like eliminating coupling is hard always you have this trade-off do you know this the international symbol for trade-offs yes some places if you walk around and you go ah other people will flash that sign back to you and it's what geeks do instead of being cool come on so there is always a trade-off between the cost of coupling the cost of coupling is these rippling changes so you got that cost and if you have a lot of coupling then the cost of rippling changes is really high and if you have hardly any coupling at all then the cost of rippling changes is low but you also have the cost of decoupling and they'll always be some coupling in your systems if you think there isn't any coupling today tomorrow somebody's gonna ask for some change to the system that will reveal oh we do have coupling here after all so you're always as a designer you're always balanced i was going to say precariously balanced but it's not really precarious it's just like this is what we do you're always balanced between the costs of the coupling that you're experiencing because of the changes you're having to make and the cost of decoupling and this is these this is this moment where you say i'm writing a book right now called tidy first question mark because all developers all the time have this experience multiple times a day this code is ugly but i have to change it should i tidy first and that is exactly this moment of software design where you're saying okay there's there's some kind of i can either reduce coupling or improve cohesion but do i do that or do i just make the change to the ugly code and it's a legit trade-off you can do the one you can do the other and you have to that i mean that's why you get paid as a designer you you have to make this call about what you're going to do what you're going to do so here's the beauty about co of cohesion coupling is a n squared problem you have n elements they could all be coupled to all the other n elements in your system and that n gets to be really large if you're talking about facebook scale or even my current employer gusto where we do small business payroll and benefits in the u.s turns out there's lots of small businesses also turns out that tax authorities and benefits providers have no incentive to make things simple so they're they're just spewing complexity and the beauty of of what we do at gusto is we take that complexity and we give the employer and their employees a simpler view of what it means to get paid we make sure that forms get filed on time and all that but in order to digest all that complexity is really really hard and no matter how good you make the code some joker in uh the oregon workers compensation tax authority is going to send you a new set of of specifications for the new regulations for if you have more than five employees which you think would be simple to calculate but it's not then you have to deduct this percentage which you would think would be simple but it's not and then six months later they say oh wait sorry we realized that what we sent you was impossible to implement so here's the new regulations and here's how you're going to retroactively apply them to all of the forms that you already oh my lord all of our data fits on a thumb drive all of our customer data carrying around in my pocket the complexity is all in this incredibly complicated rich domain and number two we can't screw up at facebook i worked on facebook messenger for quite a while and he always had some slack you know just like no this isn't going to work ah that's fine the little button that says uh i was unable to send try again you know that was always an option and we don't have that option at gusto it's not like uh i was unable to make things right with the irs for you try again does not work that way um so what we do really matter and and if we screw up badly enough we literally can go to jail i mean we can go to jail not our clients so um we have this big domain we have a bunch of code to support it which is grown organically people use organic as some kind of pejorative some kind of a oh this system just grew organically what is your other option i mean we're all carbon-based life forms right so i don't get it anyway where's what was i talking about i'm gonna get i have four topics to discuss and i'm gonna get through one of them today so um coupling and cohesion i think i'm almost there here's the thing about cohesion though coupling is this n squared problem and you think about n at a place like facebook or and at a place like gusto the number of repositories and services and functions and variables and database tables and and and is very very large that n is big and then every a change to every single one of them could break every single other one of them in some way that is going to really surprise you at 3am so that's an intractable problem as a designer you don't get to work from a clean sheet of paper you you walk in and you've got a system and it's already running and you need to make it better in some kind of way how do you reduce coupling you remember that cost of decoupling over here that's really really enormous so it can be challenging it can be nearly impossible as a designer to identify what you even want to decouple but here's the good news you can always find things to make more cohesive seeing things that are cohesive that is that are going to change at the same time and putting them in their own element that's something you can do just analyzing locally you don't have to know about all of everything i realized this as a habit when i watched one of my students refactoring he needed to change two lines of code in the middle of a big function and he the first thing he did just as a reflex didn't even think about it he extracted those two lines into their own helper function he changed the two lines he made sure that the tests passed and then he inlined that little helper function back into the original i thought wow that's a that's a waste that's like you could have just edited those two lines in the middle of the function but instead he created a cohesive element this function that would have to the whole thing would have to be replaced if any of the statements in it changed all of the statements and it had to change and then that was a much easier task what are the what's the state that i have to worry about while i'm in these two lines and i don't have to think about all the stuff that came before all the stuff that comes after all i have to think about is what goes into this and what needs to come out and that's easier that's a cohesive element edit it boom and then and then you can inline it again or not your choice but that moment of now there's not a good verb for this so i've invented cohesivating which somebody's going to come up with a better option than that it's is it maybe this is a an application of cunningham's law you know cunningham's law if you want a good answer to a question on the internet you don't post the question you post a bad answer and somebody will correct you most often a guy but that's a whole different set of political problems okay um no it's a guy if you don't want the answer changed um so you you can always make things that are cohesive uh it turns out there's two styles of designers lumpers and splitters you know about this i am definitely a splitter i like lots of little pieces that are interacting with each other in fairly simple straightforward ways um other people want to have big giant functions and big giant tables and big giant uh objects so that they can see everything all at one glance and i think this is a legit difference in thinking styles um this is one where i'm not going to say my way is just strictly speaking better uh so in this in this uh goal of reducing coupling over time if you can't get rid of it putting all the as we would say on the farm manure in one pile is better than having it spread all over the place that is this moment of creating cohesion where you're saying well we have all this code scattered all over the place that does i don't know authorization let's put it all in one place and it won't be any easier to change in that one place except that at least we know where to go to look so that's this moment of creating cohesion which tends to reduce coupling you can't always know that you're doing it but at least it gives you a path forward so there's the original definitions of coupling and cohesion coupling is if i change this i have to change that with respect to a particular change and cohesion says if i change one of these things then all of my siblings have to change too which is a way of reducing the scope of coupling now i am the sort of person who generates lots of ideas and i've been thinking out about a bunch of stuff lately some of which ties together and some of which i'm not going to be able to even come up with a plausible story for how it goes together but here's a here's an observation that i made the other day um writing this tidy first book so there's a loop that goes somebody has an idea for how the behavior of a system needs to change and they change the behavior and that gives them more ideas for how to change the behavior of the system and so this is your user sees your systems like this that behave like this yesterday it behaves like this today we're hoping that that's a happy change sometimes it is but as a developer or a designer you know that there's another loop that's going on underneath the surface you know the story about the swan at the swan up above it's all beautiful and majestic and it just glides smoothly along if you look under the water there's these feet that are paddling and poop coming out so software development is like the swan except the graceful and beautiful above the surface part thank you very much so the other thing that's going on is you you can't just change the behavior you also have to change the structure of the system too and how the system is structured effects profoundly affects whether or not you can make the behavior changes that you want because of coupling exactly because of coupling you say well i could add this database but then i'd have to go change these 20 places so i'm going to take all those 20 places and i'm going to put them in one object and now it's easy for me to change the database that's a kind of structural change that you can do before you make a behavior change and that's exactly this tidy first moment that i'm writing about where you say okay yes i want the behavior system to change like this but first i'm going to change the structure um i came up with the slogan uh let's see i just i shortened it this morning over breakfast make change easy then make easy change there you go that's your next t-shirt idea um and this is as programmers we can be pretty massive massac yeah masochistic sometimes like the pain of programming is a badge of honor where oh this is going to be really hard it might not work at all and we think that's a good moment i go good i get to now use my wizard-like powers as a programmer well maybe that's the moment that we're really screwing up maybe that's a moment where we say well making this change would really be really hard what would the system have to look like in order for this change to be easy i want to make the change easy then make the easy change well then you're just well actually making the change easy can be hard too so you have to reply recursively because i am a computer scientist i did take those three years in college of computer science where it's kind of like a zipper you say well if the system was like this then this change would be easy but to get the system like this is going to be hard but if the system was like this then making that change would be easy and if the system zip zip zip and then you can make the easy change but that means that you're spending your brain power on making the next change easy not on making the next change and that can be uh that's a hard moment uh like the the people observing these behavior changes this is an artist's rendition of an eyeball very interested eyeball whoops what go oh jesus now what if anybody no connection does anybody have any idea how to get rid of this yeah this thing here that isn't moving all right all right what is the collective salary of this room right now i don't even all right no not last cast the all right there can't even my operate my own damn computer well it's not really my computer apple keeps doing things to it um where was i so from from the uh the outside observer who just wants the new report to be printed or the new interactive video thing to pop up when you don't want it uh that's where all the pressure is i want to see the change of the behavior but as professionals we understand that the structure matters to making the next behavior change and even making this behavior change and sometimes it's important to do a little more now so that we can continue making the kind of changes that we want to make i'm going to as i said i had to skip some topics oh this is so frustrating here's a experiment to try and then i'll get to my i'll conclude the experiment to try is to carefully separate behavior changes and structure changes um like put them in different pr's oftentimes you're programming away you say oh and i need to rename this oh and i need to add an if statement here oh and i need to extract the helper don't do that go back and either do the do those in one order or the other where you make the structural changes the name changes introducing new sub elements make those changes that's one pr finished done shouldn't change the behavior of the system at all and then make you the behavior change or do the hacky behavior change first and then do a second pr to do the cleanup to make those structural changes the reason i think underlying reason for separating behavior changes and structure changes like this is that behavior changes in general are irreversible that is if we s augusto if we send out a wrong tax form we can't take it back so you have to be very careful about irreversible decisions but you don't have to be so careful about reversible decisions and all structure changes are reversible if we extract out a helper we can just inline it right that's that's not a big deal you don't need to apply the same level of rigor to reversible changes as you do to irreversible changes by separating structure and behavior changes give yourself a chance to apply different standards to what are very different sets of decisions the structure changes you can undo easily the behavior changes not so much so there's an experiment to try when you go back now here's the message that i thought i was going to come with to you and this is a big surprise to me something that sparked my interest in uh what i call a 3x model explore expand extract that i came up with to describe uh how innovation happened on facebook [Music] and it is the resurgence of waterfall-style development exactly how stupid is that well it's not actually stupid stupid smart people trying to solve real problems in a way that just doesn't work and we know it doesn't work but that doesn't stop them now we could have an interesting discussion about the psychological motivations for doing waterfall development when you know it's not going to work but the fact is if you go out there in the wild you see people saying stuff that's very waterfally now i at one point said there are no big changes they're only big feedback loops and i believe that applies to waterfall when you've specified one thing it's just so tempting to go and specify the next thing without getting feedback on those first set of decisions it doesn't work because one we can't predict and two the very act of making a change in the world causes the world to change which makes the next thing different so the waterfall doesn't work it never did it still doesn't it you know this time is different it's not different and yet there are people saying very waterfally things and we'd at least introduced shame to the equation 20 years ago or be able to go well i have this big spec and they'd feel bad about it now now no it's like i have a big speck what do you have oh a bunch of test cases somehow the idea that feedback loops just simply have to be long has come back into fashion so this is one of the advantages of being an old person is i get to look at these things come back around and he's like oh yeah i know how this one ends might take five years for all y'all to figure out how this one ends but at least i don't have to worry about it because i know how where it's going the ddd community is perfectly placed to counteract that tendency by insisting on feedback you're the people who analyze more carefully and more thoroughly than other folks do but when that moment comes when you've made some decisions and you know that they're at risk you're also the people who are perfectly positioned to say time out i'm not sure about what we've done already i'm not comfortable adding more layers and more layers on top of this let's implement something let's put it in front of people let's see how they act let's see how that changes the context let's see what we learn from that feedback loop before we start making another set of decisions based on these risky assumptions this room and your compatriots are perfectly positioned to to tee that up and say nope we're not going to continue however good it feels however much progress we feel like we're making however many insights we gain into the domain by thinking really hard about it that's a thing we need to do that but we need to spread that over time and here's how we're going to do that now i'm not quite sure how your community spreads your techniques over time in that way so i'm going to leave that as an exercise to the listeners but what i can say is in addressing our collective moment of insanity going back to very very long feedback cycles you have an opportunity a unique opportunity to address that sooner and quicker than the people like me who are talking to mostly to folks who are writing code and writing tests and think that they shouldn't write tests because they don't have not a design software and it's a long story but that's what i would that's what i wanted to come to you to say is the water falls back it's stopped apologizing and it needs to be killed with fire thank you very much

Channel: Domain-Driven Design Europe

Views: 12,666

Rating: 4.954802 out of 5

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

Id: 3gib0hKYjB0

Length: 55min 35sec (3335 seconds)

Published: Mon Oct 12 2020