TDD and Software Design

hi a few weeks ago two season XP practitioners well-known authors in the community started an interesting discussion on Twitter on TDD and software design uh however Twitter is probably not the best place to host these kind of discussions so tonight we have the pleasure to listen to them uh welcome Dave and Sandro thanks very much thanks for the invitation well thank you for accepting the uh discussing the talent um so the trigger tweet I think it was Sandra saying I believe software design should be taught before TDD tdd can't lead to good design if we don't know what good design looks like yeah uh sometimes you forget that people actually read what you write i don't yeah I need to get used to it so it was more a rant than anything else but that that doesn't mean that I don't believe on that uh so uh I think that uh before I say I go any further uh like I believe that everyone that knows me know that I'm uh an XP practitioner i believe in TDD i use TDD in everything that I do this is by no means whatsoever me criticizing TDD it's just me analyzing how I work and where my design insights come from and analyzing the practices and also of course I work with in many projects i work with many clients uh so observing how other people do things as well so if you go back in time and see some of my talks or things that I wrote you probably will find in many many places me saying TDD leads to good design tdd leads to good design and I've been saying that for a very long time it just happened that I said well it leads to me but why I'm happy with my design when I test drive so where does it come from and I realized that it may not happen to everyone and and that's why I was questioning is TDD alone as a practice a design tool or it's more like a a workflow that has triggers for me to say inspector code inspector code make it better make it better make it work make it better make it work make it better but then that's that was my that's what I was trying to say like uh I use CD always uh or almost everything unless that I'm exploring something but my my my my tweet was more about when it gets to the design phase is it TDD itself or I'm using the the workflow to say okay that's the point now that you made it work make it better or before you do something what are you trying to do where are you going so so so that that was that was my tweet about so it doesn't fit inund something or well that's why we are Sure all right so I I uh the I think one of the big problems is the uh one of the constraints that Twitter put on Sandro uh and it's the thing that I'm one of the things that I'm sensitive to as a let's say as a a careful user of language in general is that I find the statements TDD leads to good design and TDD doesn't lead to good design both of them problematic um and I and and that's what led me to write uh the article which I'm glad Sandro pulled out of me uh it's actually one of my favorite ways to write is for somebody I respect to say something surprising so that I can spend a few thousand words clarifying my position um and that's why I wrote what I wrote um that you know uh especially uh uh especially North American fans of stand-up comedy out there who know Lewis Black know that he does this wonderful routine about um how he hates when people complain about government because they talk about government as though government was this thing walking around smashing buildings government is just people and that's kind of how I felt about um or how I feel about the condensed abstracted version of what Sandra wrote in that I I find that it's no longer a good idea for us to treat TDD as though it were a thing walking around smashing buildings uh it's just an idea um I had one reader who really jumped on me and said "Calling it just an idea is a copout it's more than that it's a it's a technique or a practice." Well I think those are all just ideas the important thing is that there are ideas and there are people um and people do things and ideas don't people do things with ideas now ideas can influence people and people can use ideas to influence other people and that's kind of the point that I wanted to I wanted everyone to keep in the forefront of their mind that um TDD doesn't lead to good design yes that's trivially true because TDD can't do anything so what are the ways in which TDD could lead to good design and or when I say TDD leads to good design when Sandro has said in the past TDD leads to good design when I have said in the past TDD leads to good design what could we possibly have meant that would make that make sense and that really um that relates strongly with how and why I teach TDD you've probably heard people in the past say TDD is not a testing technique it's a design technique and I used to say the same thing for years and that's one of the first like that was where behavior-driven development started to come from was uh be it's a shame that they chose the word test because that confuses people and makes them think that TDD has testing as its primary goal and I think we all agree seasoned TDD practitioners all agree nobody really intended for TDD to be a testing technique although I'll ask all of you out there who have picked up TDD um I'm guessing that defect rates was one of the reasons you were interested in TDD in the first place that I'll bet you one of the things that attracted you to TDD was maybe I could find some of my own mistakes instead of waiting for testers to find them so TDD has uh the fact that test is in the name is not necessarily a disaster it's not to say that TDD has nothing to do with testing clearly it does that's why the word test is in the name but we get to this point where we realize we we get this picture that TDD has more potential than just being a way to reduce um shipping defects to other people that TDD also has this wonderful potential to remind us as Sandro said in his in his opening statement to remind us to think about the design as we go rather than design being the thing that we think about at the beginning then writing code then testing it we have coding testing and thinking about the design all at the same time and so that leads people to say things like TDD isn't a testing technique it's a design technique and I said that for years and people that I respect said that for years i'm sure Sandro has said that for years or I should say I'm sure Sandro said that for years and probably doesn't say it anymore uh because it occurred to me the more and more that I taught TDD um after several years of doing it and seeing people go through the process of going from code and fix to writing tests first that TDD offers an opportunity that goes beyond simply design towards learning how to design towards learning what makes design better learning what makes some designs better than others And I liken it to there's this fantastically wonderful book simply called chess um and any anyone who's a chess enthusiast out there probably knows who the Pulgar sisters are there are these Hungarian chess wiz uh there I think two of the sisters are masters u in fact I think one is a grandmaster they were taught by a maniacal father to to learn chess from a very early age and their father was very big on um the the theory of showing the girls examples of chess positions and having them learn chess as though it were a language the same way you learn how to speak English or French or Spanish or Portuguese or whatever the how did you learn your language the language you grew up with well for a couple of years you listened to a whole bunch of people speak the language and you somehow figured out some of what was going on and then you started trying to speak the language you took what you heard you abstracted away some patterns and then you tried to use those patterns to construct sentences and then people told you I first you got a signal whether people understood you and second you got a signal from people telling you no that's not how we say things i know the rules say you should probably say this but we actually say it that way i don't know why that's how I learned how to speak English that's also how I learned how to speak French how I learned how to speak Spanish how I learned how to how I'm learning to speak Swedish um and that's what I think TDD gives us i think TDD gives us a mechanism for learning good design the same way we would learn a language um specifically the uh refactoring frequently part of TDD gives us a whole thousands and thousands and thousands of opportunities to see a design to evaluate it to find out whether we understand it to try changing it and then to immediately get feedback on whether the change is an improvement or uh making things worse or simply changing it and this is the part this is the reason that I say TDD is not a testing technique it's not even a design technique it's a learning to design technique it is a mechanism for us to learn what makes designs better the same way that we learn how to construct a proper sentence in any language that we speak would you say that is a almost like a verification of your design theories well that's part of it so part of the TDD mechanism part of what makes it a learning mechanism is that it gives us the opportunity to evaluate two designs that are very similar but slightly different side by side i'm speaking just about the refactoring part of TD so the step where we actually try to improve the design right um we make a small change and some of the time it's very clearly an improvement right we have five copies of something we extract a method we call it from all five places 99% of the time we'll agree that's an improvement now part of it is also that we have been primed to believe that removing duplication is a good thing um but we also understand that there are some there are some reasons to say some objective reasons to say that calling the same function from five places is better than copying and pasting 12 lines of code to those five places there are some refactorings where it's clearly not an improvement right um and this is again a part where the language becomes a bit um complicated or not complicated but dangerous because we have refactoring meaning improving code and we have refactoring meaning a change to the code which might or might not improve it so there are some refactorings we can apply we can in introduce template method we can uh extract a superass we can um uh introduce an interface and sometimes that makes things better and sometimes that makes things worse and when we apply those refactorings when we make those changes we have the opportunity to ask the optometrist's question right better worse or same and sometimes we don't even know whether it's better worse or same that's when we then need to go and ask other people that's when we need to go onto the mailing lists call our our friends over maybe we're pairing maybe we're not that's when someone knocks on Sandro's office door and says you know I'm not really sure if this design is going in a good direction what do you think and you learn from people who have more experience and that's exactly the same as taking your manuscript to a more seasoned writer and saying I'm not sure that this passage really paints the image that I think it should paint i want to paint the image for the reader of this thing and I'm not really sure if this passage does a good job of painting that image what do you think and it's exactly the same kind of you know judgment and so you know we've had discussions over the years um on the mailing lists what is good design nobody knows nobody has a way of defining what good design is no matter what definition Sandro offers or Ron Jeff offers or Kentback offers some of some one of us can create a counter example that fits what they said but we agree is bad design it's more subjective than that it's not as easy to define we know what bad design looks like we've all seen it and so that's why I I like to say that TDD um the way that TDD leads to good design the sense in which that statement is true is TDD in the hands of someone who's paying attention can guide them towards good design in a way that simply reading books on design won't do because it certainly didn't for me i remember reading object-oriented analysis and object-oriented design when I worked at IBM and it would have been more effective to smack me over the head with the books because I just didn't understand what was going on but when I started it was too alien to me but when I started to see gradual changes to my code and I started to notice the ways in which those changes represented improvements how it made future features easier to add how it made the code easier for other people to understand it um slowly but surely I started to internalize then really understand what the code and Jordan books were trying to teach me and that to me is the sense in which TDD leads good to good design can be true um it's like it it's like um sometimes you need five different people to tell you something before you'll believe it and only the fifth person is the perfect trigger because they know exactly how to say it in a way that makes sense tdd knew how to teach me those things in a way that made sense to me now of course TDD didn't do those things because TDD is not a person but the act of practicing TDD asking questions that's what unlocked this uh understanding in me in a way that simply reading books didn't do that simply reading mailing list didn't do and to me that's the sense in which TDD leads to good design what what would you say that for example because you started with TD very early on uh your career uh so that's TDD was a way that you learned that's how you should develop software of course that you ran into problems in design problems you happen to be using TDG because that's you were lucky to be in a place where you started you were to work on that way uh for example I had a very different experience so I started in the mid 90s and I I'm from the the the the era it looks me very old makes me very old now it's only a couple years older than me go on so where for us like a developer our aspirations was to become an architect and becoming an architect meant you need to learn UML uh all the the the the many diagrams that you have uh design patterns big thing when I started 1995 so you had to know them and we would spend uh months uh creating class sequence component all the the the diagrams before you would write any code and we would go we would go like to our design pattern book and say right those are the patterns that I want to use now let's find a problem to put them in right so that this was bad we we kind of uh many people in the java world like myself we overengineered everything but there was one good thing about it it's from the early days of my career we were always thinking about how to model our domain how to we we made it we did it wrong right that's not the right way of doing things but but at least we were thinking very hard on design and trying to learn as much as we Right and if we didn't have design patterns we might never have had analysis patterns we might never have had domain driven design exactly so so that's the other thing because I was always fascinated by software design from the early days of my career and called bullet and everything else but I I I only met TDD more than 10 years later because I've been using TDD for like about nine years i have almost like 19 to 20 years of career so half of my career for almost a decade so my obsession was design i was early adopter of domain driven design so I was learning design without TDD but I was suffering the pain of bad design because I had to maintain that code not just myself entire team so it was not just a matter of like tests were were showing me no I was seeing that because I had to maintain the entire system uh so I I think that uh the interesting thing for me was when I first of all I rejected TDD because I thought that I was good enough and I didn't need that uh so I know how to design and and how to code so I don't need this crap um and but then after some some some guidance and and some people that I really trust and kind of kind of from one person in particular that I consider like was a great mentor for me when I moved to London he said like you have a lot of potential why don't you at least try it and for a whole month I was banging my head against the wall uh because like I'm slow i cannot that doesn't make sense it's just easier to type something i know this so but there was one thing interesting for me because I had a very well I had a very good design background at least I I learned a lot practicing and reading and stuff i believe that different styles of TDD they have a chance to to I believe that first outside in when compared to the process uh if I take this approach I I'm I still can see how TD can lead to a a good design or can be used as a design tool the cost assist approach uh that is normally the original one uh that's the one that is easier because like just to clarify the in my view what the difference means in terms of design in the outside in design starts at in the red phase you write your tests because you are testing collaboration so you are already making a lot of design decisions while writing your test you say I want to test this class but my test is about this class class a smoking to class B and getting in class B and maybe interacting with something else so you I like to think of that I like to think of that specifically as um the the emphasis is on avoiding uh violating single responsibility the idea that as soon as you recognize that two unrelated responsibilities are coming together you say no I want to separate them let's put an interface between them exactly so so this the way I go about it okay I need to I have this class that I want to test and I want this method in this class with these parameters what should happen when I call this method then I list if I can list more than one thing so so we need to do this and that and that that so it needs to validate the user account and then see if it has a prime account and then make the payment and then validate the details send an email confirmation so of I already know that I cannot write system in there so for each bullet point each item I say does this behavior belong in the clause that I'm trying to test or belongs in somewhere else so my design starts while I'm writing these tests and the refactoring phase in the outside uh outside entityd is much smaller it's a refinement it's usually a refinement or it's detecting a uh detecting a design blind spot it's saying "Okay I thought I wanted these things to be separated but in fact I want them to be together." Or "I thought or I thought this was just one thing but it was actually four things and I couldn't see the four things at that level of detail." Exactly i talk about the difference between uh a type discovery and type confirmation and the classicist approach is type discovery we force every type to justify its existence type confirmation says "I'm going to make a guess about which types I want." And the feedback from writing the tests will tell me whether I'm on the right track or not it's a shortcut i treat it as a shortcut yeah no that that that's that's how how I feel so So the outside entd it's much harder if you don't have good design background if you don't understand domain driven design if you don't understand solid and many design princes you cannot beforehand without any feedback with no help whatsoever you are complete on your own right so you are writing a test you are complete on your own no feedback but you need to think in your head like okay I should have this collaborators this should be respons so you need a good design understanding to go there uh it's much which is which is exactly why I spent two years trying to convince both clients and attendees to training classes to let me not teach them mock objects for the first for the intro course I tried that for two years and too many of them said no we need to know about mock objects and I and it's like you know when you're your your your children tell you when it's time to let them use the knife in the kitchen you keep saying no as long as possible and eventually they say no it's time for me it's time for you to trust me to you know cut the carrots fine at some point you have to give them the knife and it took me two years to really feel comfortable saying to people uh look I'm going to show this to you uh I don't think it's a good idea i think you need to do you need to practice this stuff first but uh you know it you're going to do it anyway whether I tell you to or not so I'm gonna at least show you so you can do it a little bit more safely um thing is just my thought like so when I see the classicist because that's the original approach and that's how I tried and banged my head and and so what what was difficult for me because like the nests approach design happens on the refactoring phase so when you get feedback there's a lot of advantage with you don't overengineer uh you wait for feedback right so but the disadvantage is uh you make a mess first and you also need to provide some query methods because you need to query that stuff or you're building this stuff and sometimes you need to methoding that because how do you test right what is a text you don't I I think more than anything else the the the classicist approach which same for me which I learned first um and practice first uh really I think it really forced me to you know it forces you to deal with the the with the problem of adding something just for testing compared to the mockist approach which forces you to deal with the question am I making too many decisions up front and I think that uh that's one of the primary reasons why I too emphasize people practicing these straightforward classicist statebased approach first because it teaches them uh it it it it's a very good detector for overengineering that's I think more than anything else the class assist approach to TDD is an overengineering dete an overdesigning detector it it retrains you to um stop tr it trains you to stop trusting your instinct about how to design things it it's the unlearning phase so especially I mean I didn't spend 10 years in the UML design patterns world before I discovered test first programming but I did spend four and I can remember doing all the same things that you were talking about i remember uh you know sitting there with rows open and trying to draw diagrams and I even remember thinking model driven architecture was a good idea for a few months back in 1998 um and I uh so I still had some of that to unlearn my big problem was that my designs when I started to try to actually write the code I I could make the code uh instantiate the design but then the code had bugs and I ended up doing crazy things like paper tracing through my code to try to figure out where the problems were and I started to notice that there were some mistakes in the code that I couldn't see because of the way I'd chosen to design it even though using this design pattern seemed like it made a lot of sense and that was what made me interested in test first programming in the first place so I I probably had I had less confidence in the UML design pattern up the the big design upfront approach than you did because I had only done it for a few years instead of a decade and so when I came across test first programming there was less to unlearn um and maybe that maybe that is a a big difference in the uh in our uh conception of the role that TDD played in our in our way of learn in how we learn design um there was a lot that TDD taught me that confirmed what I understood from the UML design pattern stuff that I'd read and learned there was a lot of stuff i mean I you know the whole encapsulation issue uh any programmer out there who has practiced TDD for more than a year who hasn't stayed up you know who hasn't laid awake at night wondering if encapsulation is wrong uh hasn't thought about it enough um that's one area where it took a really long time for me to understand how encapsulation and abstraction fit together um which now something like event sourcing is now the is now a shortcut to that right event sourcing takes you directly to well if you think of things as events then you're going to be at a higher level of abstraction than normal and encapsulation kind of happens free um but I'm digressing a little bit but uh so I'm with you and I I had a similar experience but just I because I didn't spend as much time with UML design patterns um and forgive me how this is going to sound i I'm going to suggest that the design patterns big design upfront approach to design it's possible to learn how to design well using that as a foundation but I'm guessing it takes longer oh no but but I mean like like I didn't want to sound like I spent 10 years doing UML and design pass because that's not true but I learned them very early on in my career for 10 years I had that knowledge that doesn't mean that how long it took you to how long it first took you to do test first was longer than me that's the only that's the only I was exposed to other techniques much before right so not just on the the design part but like proper object oriented design and right coupling and everything else so uh but I was not like modeling with UML for 10 years no that did not happen yeah yeah yeah i I think I understand you that the the you had more of a you had more of um if I can say more of a theoretical path to learning like you learned uh design principles more from the principles themselves whereas with TDD as well with with test first programming in general I learned it more from concrete examples up yeah I did with concrete examples I just didn't want didn't have to the tests as a an extra constraint my was like we need to deal with the mass now right right uh so so that was my and why did and why did we end up in this mess how could that happen we used patterns how could that happen exactly where is the domain i just see pattern names in here right so so yeah those are lessons that I learned so the for me TDD was a a great way I had to unlearn of course uh but it was a matter of refining so for example because uh like the background I'm not talking about like I'm talking about like solid and all the the tail and ask and principle of fist astonishment and cqs and domain driven design everything like even the the four rules of simple design everything else that we have out there the types of MVCs and coupling cohesion delivery mechanism and core domain and all these things right that are out there that are related to the domain so for me when I got into CD after 1 month uh that was kind of like shook my uh my my world a little bit but that's okay I understood the mechanics now so so for me so okay so that's actually not hard now I understand like I so I wouldn't I was not overeng engineering anymore but I was not throwing away the the things that I already knew for example the the reason that I make a clear distinction between between the I don't like the mockist uh so I don't like classist mockist i like outside in classist because mockist is is just something that you may use uh like in the outside in normally use more mocks and but it's it's just ah but you can do you can do outside in classist there's nothing that stops you so the the the the for me like the thing was when I work a lot with business applications normally the vast majority of the work that I do I have a product owner right I have a a business expert we are building I don't do frameworks I don't do loads of data manipulation I don't do a lot of stuff that I need to explore right that for example I have a requirement that you have an input in here I I know what the input is I know what the output is but there's no domain expert that will say this is all technical stuff you need to do all manipulation all crazy is you are on your own so that is I think that's when I flip to classic system immediately I have no idea what the solution looks like right not even guess I don't have a domain language that I can refer to and look for nouns and verbs I have nothing I have inputs and outputs okay let's do class six let's start exploring let's see what tells me let's see if the types will emerge let's see what I would need so I believe that the the uh the the most proficient uh TD practitioners that I know they flip between class system and outside in even thinking right so they don't even think oh yeah now I'm in this mode now in that mode no that this is a problem that's how I solve it this is a problem so but outside in for me having the the a little bit of design knowledge is much easier for me when I get a user story with acceptance criteria it's almost like you know when you have like the the like you see news uh on news on TV and they show a letter from someone and some words So the whole letter becomes blurred and then some words jump that's exactly how I see user stories in outside criteria i see the nouns and verbs immediately right as soon as I see nouns and verbs for me it's very easy to drive from outside and say okay this verb belongs with this noun so it's not hard for me because I've done that for a very very very long time so outside entity it just happens normally i know where things would go and I can help I can use the feedback domain language more i don't want to create a mess first and because I know roughly where this is going and then I will use my domain driven design knowledge and my so that's what I meant when so when I see yeah 3D leads me to a better design but it's not 3D itself 3D provides me the frame the mindset of say that's how you that's where you think about the design make it work make it better think about that's outside in or and I like those two I like those two points they both they're both important and they and they um they're they're different but they work together first the mechanism of TDD provides the opportunity the reminder the chance think about the design but not only that that TDD also um shifts the practitioner gradually shifts their mindset away from design as a separate activity towards design as optionally a separate activity and optionally an activity that's wrapped up in writing code and I think for I know for me um you know uh practicing testpers programming was an exercise in I'm going to try making no design decisions up front and see what happens and I'm going to live like that for a while and it's going to and it it felt weird um there were some things that surprised me and some things that didn't that that was when I learned but I reached a point after a few years where I started to ask the question does practicing test first programming mean that we need to forget everything we ever learned about design and clearly the answer is no uh the you know nobody intends for you to force every single design decision to come from feedback from a test i I as a teacher I expect people to be willing to do that for a while i expect I in fact I explicitly tell my students I want you to forget everything you learned about design for the next three days what you do after I leave is completely up to you i'm asking but I'm asking you to do this for now um because you'd be surprised what this stuff will teach you some of it will confirm what you already believe some of it will challenge what you believe and it'll be different for different people and that's why I'm asking you to suspend what you know um I want I I think I've done my job as a teacher if I get everyone in that classroom to the point where they are confronted with an extremely uncomfortable design decision where the rules tell them to do something that feels really weird or where the rules don't tell them to do something that they think they need to do um because that's where I think the learning really happens um this is something that I talk that I'm going to talk about in my uh onaggile um conference talk uh next week um the to me that's really kind of the point but once you've spent time uh entertaining the possibility that all everything you ever learned about design is wrong clearly not everything you ever learned about design is wrong some of the things you've learned about design are wrong sorry um they're wrong in a certain context they're certainly wrong in a context where the rules have changed where you know where we're not uh accepting scrolls from an architect and typing in the code but where we're decentralizing architecture decisions and everybody has to become an architect um where everybody's making the kinds of decisions that traditionally a single architect would have made in those contexts the rules are different and you need to understand design differently than you do if you are designing a system once and then having an army of monkeys type um so that that to me is kind the the shift in mindset to me is the important part but as you say I I don't want people to to use tests as um I'm not expecting them to forget everything they ever learned about design after a while after you've seen what the what doing what letting the test drive the design has told you to unlearn so once you've unlearned what you needed to unlearn then you have the experience to experiment and say "All right I've solved this problem a hundred times before so I feel very comfortable using a uh making more guesses upfront about what types I'm going to need or I think I understand this domain really well now so I'm going to guess that we're going to have these five core domain classes um I have done so many web apps with the MV with the web MVC style MVC style that uh the pattern of request comes in go to the model get a result create a model and view response object and send it to a template engine to render that pattern is so burned in my brain it's funny that we've come back to design patterns now we actually do we're using design patterns in the way that the books were telling us to do 20 years ago uh the difference is we understand why well the so not just that we understand why but the consequence of the fact that we understand why to me is the most important thing and that is that when the design when we try to jam composite into a design and it doesn't fit we stop jamming that's the difference between us now and us 20 years ago us 20 years ago we'd have taken out a hammer and smacked that composite into the design until it until it it sat there whether it fit or not exactly um but now we have other techniques what we can do is now step back and say there's something about this this is not making sense to me cop as it seems like it fits here let me now try writing some tests let me pretend I don't know how to design this part of the system let me write some endto-end tests for this part of the system and see what happens when I just remove duplication and fix names um it's the same thing to me with the classist mock mockist or uh top down bottom up or outside in inside out uh everybody asks which should I do and the answer of course is always all of them because the more you know how to do all of them and the more comfortable you feel doing all of them the more easily you'll switch back and forth between the two and when one's not working you switch to the other and so yeah I'm not a classicist i'm not a mockist i I I'm a lover i do it all and there are some sol there are some I there are some analysis diagrams that I look at and say I know what five key patterns are going to be needed here let's just try it and see what happens when I get feedback from the tests that tell me that this layer is not necessary I get rid of it and I don't care that that layer is in the original design and that to me is the big difference is what happens when your original idea starts to break down and 20 years ago I would have insisted that the original idea was correct and I would have kept on it now I don't i let the design emerge and to me that's what TDD is as a part of my TDD leads to good design in the sense that I never feel like I have to commit to my original idea and and maybe that's not that's not TDD that's the evolutionary design part of TDD that that that is the the workflow i I think that that that's cuz that that's the thing right so in the classic system yeah definitely when I don't know where I'm going I let it emerge for sure do that uh in many parts cuz like an application is not like a binary like all all the things that we need to do are user stories and have a domain area there so there are parts that you have the user stories and then right in the middle one of the the acceptance criteria yeah you need to enrich a trade with data from the other system yeah but you that you need to understand laws of XML you have no idea what you're going to do with that i flip to class in the middle of so I start outside in and then there is one step that I need to I have no idea what to do with that and I will flip styles and then like exactly and that and that's what I really like about the the the the programming to interfaces um is that it becomes really easy to then take that small part of the system and ignore the rest of it exactly it doesn't exist this is the context independence that Nat and Steve wrote about in growing object-oriented software right that the idea that because we build the system in a way that the pieces don't depend on their context I can treat this as though this were the whole system and I can do classicist work design uh purely evolutionary emergent design on just this part and it doesn't matter that this implements an interface that's being used here and that I'm mocking it in the layer above i don't care exactly i I I I treat everything like it's a tiny system yeah and then to clarify the the the way that I use outside of course I'm making lots of designs at testing level but that's why I said that uh see this for me like now is more like a ver verification mainly the outside entity is a verification of my design theories because like I write test and say like that's how I think that I should go about this but then I still have the refactoring phase and when I look at it and I don't like I said no this is looking really ugly i made these collaborations here shouldn't happen it should be together or no like there or it could even be it could even be you know what uh uh until we added this new feature that was the only time that was the interaction that was the level of abstraction we needed for that interaction now I see that we have actually three uh consequences of an event of a of a of an interaction instead of one ah there's an event here let's invert the dependency off you go that's exactly for so Um TDD I I think TDD kind of does both it it it the sense in which it leads to a better design is it provides a mechanism for learning what good design is as long as the practitioner pays attention and has people that they can ask for help but it also provides a continual reminder it's this it's it's it's the annoying guy in the corner who keeps poking you saying "Are you sure are you sure are you sure are you sure you want to do that are you sure that's a good idea um and so it leads us I mean let's just say that TDD is one way that we lead ourselves to better designs it's just it's nicer to say TDD helps lead us to better designs um and so yes we can almost say that TDD creates this feedback loop where if you don't know anything about design TDD can you know is like the owner who's taking the dog's head and saying look at what you've done uh it's it it tells you pay attention to what you're doing um maybe it doesn't do that strongly enough but it tells you pay attention to what you're doing think about what you're doing is this really okay um and and it acts as the continual reminder yeah because like use what you know to evaluate what you've done because the point I was trying to make is uh for people that really can see things or they they have I don't know it's easier for them to spot is great but first of all how many like you you you do consultancy as well like how many times like many of us have seen the refactoring step being skipped they do red green red green right so so they are test driving crap so but people I would even say they're not test driving though right and you might argue that this is just a play on words but I think it's I think that the step from test first programming to test driven development true is a big step so if so you know again one of the ways that I like to teach is to say Philip say okay this is test first test driven design because like you are not adding anything like when when you say this is test versus test driven design okay this one says you need to pay more attention but that doesn't really teach you anything and that that was ah ah but it did for me and let me tell you the difference you need to be able when defects stopped being my bottleneck that's when I started to change from test first programming to test-driven development and I I tell people that this is this is a common pattern a lot of people have told me they've gone through exactly the same thing the a lot of people get interested in TDD because they have serious quality problems and they think testing is going to help and test is in the name and then after they practice test programming for a while even before they have any understanding of how it could improve their design they see that it reduces their defect rates eventually there the the the num the number of mistakes that they ship outside the team stops being the bottleneck and what starts becoming the bottleneck is the quality of their design and how it impacts their ability to maintain the system over time that's when they become more interested in pay more attention to and are ready to receive the lessons of design improvement and that's when they start refactoring more may just like I'm conscious of I don't know exactly how much time we have here but I'm open yeah I'm okay as well whatever you want whatever you want all right so because there is another thing that I would like you to raise because like uh there is the micro level the micro level I think that what we've been discussing so far is me as a developer on my own or with a pair working with a single task right and then we are testing after test trying to complete this user story or whatever we are trying to do and then we are in this micro design yes so letting the things emerge and work well for that specific thing what I want you to brought up and that's one of the other things that led me to to write a tweet was very rarely or at least not it's not my case at all i normally work with larger corporations with many teams many developers and stuff so TDD leads to may help you with the the the micro design but like there's not we need to worry about design at a much bigger scale and there's no in there right there's a whiteboard and that's not whiteboard there is for example what we need for example I'll give you some more concrete examples we've been working with a client they have a huge system to build and they want to do things in parallel because we don't need to do that with two develop velopers pairing for 10 years right we can have like a few teams working in different parts of the system well first of all designing which parts of the system how you split your modules so people don't step on each other toes that's part like there is architecture so I make the difference like the tools that you choose Java and then there will be messaging and that's database and stuff uh and then there is design like which modules I'm going to have how do I split of my so so people don't step in charge because I cannot rely everyone working on the TDD cycle and expect that I'll have a coherent design I'll have like a consistent consistency uh across the system because that's important as well even if you pay a price where some things that's always a big debate like but this does this fit here or not but like how do we enable people to work in parallel deliver software so there is a lot of design that goes in there as well so those are kind of design so TVD cannot lead to a great design at this scale when so when you go beyond two people like and you have like that's my opinion okay ah but I think it can and here's how I think it can so um so uh there's a few things swimming around in my head but I so the first thing is a philosophical point and that is that I I'm a firm believer that the same kinds the same kinds of general principles that make design in the small better also tend to make design in the large better so loosely coupled highly cohesive modules um by definition cohesion is fractal so uh it seems to me that things that improve cohesion work at every level of the design um having loosely coupled modules with well- definfined contracts between them similarly works well at all scales um this was actually one of the earliest um points one of the earliest things that I attributed one of the earliest um highle design principle ideas that I think I think that TDD taught me although it's possible that it didn't but the idea of self similarity of design that the design principles are fractal they're self similar um that for the most part I can apply the same design principles at every layer of the system and that and that's fine they'll they'll work everywhere um so now let's assume that I let's assume that that makes sense if that's true then the better I am at micro design the better I also am at design at every level of the system add to that the more I practice TDD the more experienced I become as a TDD practitioner when I become comfortable with what we were talking about for the last 20 minutes about practicing TDD doesn't mean throwing away everything I know about design practicing TDD doesn't mean uh or practicing um mockist uh or let's say designing with interfaces doesn't mean that the interfaces are published and unchangeable um that I can even if I design with interfaces I can still take still if you put those things together at the high level what does that look like well at the beginning of the of the pro of the you know when we're actually ready to start building the project we make a guess about how many big subsystems we're going to need we guess that we need five uh we we guess that all five of them are big enough that they need their own teams of four to 10 people so we make a guess and we hire 40 we assign 43 people to the project we put them on five teams um you know and Conway's law kind of kicks in a little bit but we're willing to accept that for the opportunity to we think hit the ground running a bit faster so then what that means is that among the five modules we need to have very well- definfined contracts at that high level exactly the same way as we would do if it was code at the tiny level um we need to make sure that those teams understand how their code is going to talk to each other across their interface between them um the interfaces might be bigger but the the the need of the need for precision is not any different there it's just that the interfaces might be a bit higher level or bigger bigger objects being passed back and forth whatever the better I am at being able so TDD was the way that I got good at understanding the importance of having well-defined contracts between loosely coupled highly cohesive um components um it led me in that direction whether I wanted to go there or not i didn't learn that I I could have learned that from a book but didn't that's an important distinction I want to make it's not like that wasn't in a book but the way it was in the book I I couldn't understand it at the time tdd helped me be able to understand what was in the book uh it just fit with my brain as long and not only that but the TD practitioner who does who is the architect who says we need five teams with 43 people will also be the person who will say after 3 months when we realize that the interfaces between these two components are getting overly complicated will say hm maybe that was a mistake we need to redesign the interface a level of abstraction higher take some of the behavior that we thought was going to be on in team one and move it into team three and maybe that means moving two people from team two into team three that's something that someone who doesn't practice TDD is probably not going to do it's going to be easy or let me put it this way it'll be easier for the TDD practitioner to feel comfortable moving those teams around in response to the design feedback they're getting from how complicated it is for a team to deliver something to another team compared to a more to someone who has never practiced TDD who has never experienced the power of evolutionary design and maybe I shouldn't say TDD but evolutionary design you know they're very wrapped up in each other um That is one of the ways in which I think TDD maybe not leads to but is maybe isn't even a necessary agreement but I think is an important ingredient in the mix because without belief the nonTD practitioner doesn't believe the feedback they're getting from the design the same way that a TDD practitioner does so I I I question that and I and I once again we have very different backgrounds many of the early days of our career uh so for example very r uh very rapidly in my career I went to large organizations and we were doing distributed systems and I did cor and decom and I did a lot of uh distributed systems with RMI and EJBs one rejs 2 and all this sort of stuff yeah I also came from uh the client uh server world where the the database was the integration point and then moved from three tier uh three layer three tier applications so for example so I learned about interfaces i learned that having database as a center piece in my design is a big mistake so I learned that how different uh the the the granularity of my interfaces when we had the distributed systems using old technologies in in in the '9s how painful they were so I learned certain things because of the pain of implementing these type of systems right every time that we had that we got an interface wrong how painful it was to change all of that right however I'm doing distributed systems right now in completely testdriven but certain decisions are still being done up front but like we do that in a mar way so for example recently I I showed this uh I gave us a lightning talk in Socrates uh canaries So working with this client new client they want to scale very quickly because they have like a large system as I said so how do we start instead of having I tow our architect and diagrams we start with impact mapping from go that's the goal that's for whom uh that's what we're trying to build uh that's what we're trying to build and oh that's why we're trying to build that's so why is the goal who what and how so the how is the features right so we had impact mapping we had a two-day workshop trying to figure out uh roughly what was the thing was no no details high level features right so the the first level of uh the first three levels of impact mapping to your business the last level that is the how that is the feature level that's more systems then what we did we went through feature by feature and said if we had to put that somewhere what would what would we call that oh this this seems a media thing this seems a feed right we are building a social network so what we've done we were looking at certain things and we were grouping them together according to the the the domain language and then the things start to evolve and transform in terms of how we were grouping these things what we were doing there we were actually defining bounded context from domain driven design so we came up out of aspirational features high level features with a bunch of bounded contexts those bounded context were what led us to create our independent services right so now we say okay that's the the way that we're going to split that all related to domain language and how it impacts the the end goal right and also when we started writing the the stories we knew which ones would go across uh we didn't create all the services one go we didn't define interfaces when we we just create they seem separate things the interfaces were only created after we had user stories and say okay now this system needs to ask for information from the other one but that was and then interface was created interface are being designed as we go along in its story so this way we are still having the design emerge but it's a much higher level so TDD wouldn't get us there well so and now that you've said that there's a couple of a couple of things that just kind of crystallized for me one of them is that I think what you and I have in common was there's something about us i don't know what it is that made us um cling to our initial ideas less than other people do i mean one of the things that makes uh one of the things that makes software design over time difficult one of the things that makes managing projects difficult is when designers cling to their initial idea of what the design should be and they're unwilling to change it even in the face of very clear feedback that uh their design isn't working um and so I think perhaps the reason why you didn't need TDD to lead you in that direction has to do with you had an inbuilt um willingness to change your thinking in the presence of new information in a way that a lot of architects senior designers uh longtime programmers simply don't do they assume that their first idea is the best idea uh I mean in a very in a in a way that you know uh you could define senior programmer as a programmer who has learned that he's not always right the first time um so there was something about you and me that made us willing to change our minds when we were confronted with feedback that told us that our original ideas about the design weren't quite right or that let me say it a different way when we discovered aspects of the design where our initial guesses didn't fit as well as we thought because by and you know the more experience you and I have and our listeners have out there the better their guesses are going to be about what the design should be one hopes right that's almost kind of the definition of experience um if your guesses aren't getting any better then you're not really getting more experience uh so you need TDD i think TDD is a way to unlock in us the willingness to change uh the a way to make the programmer feel more comfortable changing their design after they've started to build it in a way that never seeing TDD perhaps doesn't do now it turns out that you discovered that a different way that you either you already had it in you or there was something else that you learned i think where uh practices like DDD what or even mockist style TDD and the boundary between those two gets blurry they enable us to guess better about what the design is going to be mhm tdd helps train us that when our when something starts to feel weird our first impulse is to change the design instead of do more of what we thought we should do right the typical firstear manager problem if something's not work if a practice isn't working do more of it i think there's something else that happens with designers right if if your if your design doesn't fit then just hammer it harder until it does fit things like DDD designing to interfaces design by contract um gaining experience in these areas uh help us develop better guesses about what the design should be help us make better decisions up front when we make decisions up front practicing test first programming test-driven development evolutionary design in general helps us become more comfortable changing our decisions in the face of feedback i'm never going to claim that TDD is the way to become comfortable changing our minds it's certainly not the only way it's probably not the best way i'm willing to say it's a really good way and it's the way that fit me really well so I would say that if TDD can lead towards better design it does that by strengthening maybe unlocking or unleashing a programmer's latent willingness to change their mind to let the design evolve it's like everybody in them has one axis which is how good they guess and one axis which is how much they're willing to let the design evolve in in response to feedback like you were doing and I was doing too back in the EJB2 EJB1 days where we started oh my god we have the N plus1 query problem we're going to have to push this stuff from the client to the server um some people thought some people learned that by uh reacting to performance problems some people learned that by reacting to this nagging feeling in their mind that the API was not easy to use and I think the difference between the people who have done evolutionary design and not is the people who've done evolutionary design say well we can just change it whereas the people who haven't done evolutionary design assume they can't assume that once that interface has been written and implemented it's set in stone and I think TDD pushes us in the direction of questioning how dry the cement is in a way that never practicing TDD doesn't do now that's not to say I don't want to claim that TDD is the only way to convince people that software is soft but TDD is a pretty damn good way to help convince people that software is soft and they can change it and never being exposed to TDD risks never really internalizing the idea that software is soft the working with clay metaphor that Word Cunningham always used so maybe TDD leads to good design only in the sense that it increases the probability that a pro that the average programmer will believe that they can work the clay whereas the average architect who's never seen TDD might be prone to believe I only have one shot to get it right and once I get it right the cement dries and I'm screwed and the only way to fix it is to break the cement into powder and do it again and I don't want to do that and I certainly don't want to be seen doing that because if I admit that that mistake that I that decision was wrong I'm going to get fired maybe that's the sense in which TDD is the essential ingredient um that without seeing that it's much less likely that a programmer will feel comfortable changing their design once they've implemented it maybe I don't know because like I uh there was a I was in a conference uh last week in in Budapest and and one of the guys uh one of came to me and said like no because you you have a responsibility you cannot just say that things like to good design and so uh because like there's a lot of inexperienced people and stuff so I understand that I I I fully I fully do like it took me a while as I said like to to understand that people actually listen to what you say and so the the but at at the same time that what I told the guy said like okay there is a learning so you are teaching someone so they are the the novice in the DFL model of skill acquisition yes so okay yeah you need rules but if we the experienced people they only talk about a subject always thinking about the device nothing moves forward nothing gets challenged because no let's do this way because that's the rule and everyone so we only talk no I know I'm not throwing away everything that I've learned and I'm not going to do I'm not going to create a mess if it's clear in my head what it's going to look like and I always have the refactoring phase two as a confirmation you know I just had this argument with somebody last summer uh I don't want to say who it was but I had a long talk with this person because we had this exact discussion where this person accused me of not doing TDD because I was taking a mockist approach and that meant making design decisions up front and I spent an hour trying to say look no no no no no um it's true I didn't let every single aspect of this design emerge and it's true I probably let relatively little of this design emerge compared to the way I would have done it 15 years ago but I I don't understand why you would call that not TDD because as soon as the design as soon as the tests start giving me feedback that my layers aren't working I'm going to change them and that to me is the difference that's the the the the the first D the whole the driven part to me isn't it doesn't mean thou shalt let every design thou shalt defer every design decision until you have evidence what it tells me is I in a situation where the tests are telling me to do X and my intuition is telling me to do Y I do X that's the sense in which it's test driven that when when my conception about what should happen no longer matches the tests I side on I always on the side of the tests i always trust that the feedback the tests are giving me is more accurate than my preconceptions and I know that if I push things I'm eventually going to figure that out that I'm going to design myself into a corner eventually and the degree to which I trust the tests is the degree to which I'm letting the test drive the design even if I make in this one instance in this one part of the system 75% of my design decisions up front they're guesses they are hypotheses they're always open to change in a way it's like doing science you know it's not when I when I uh you know every law in the scientific world is is liable to be struck down by a single counter example um every design decision I make is liable to be struck down by a set of tests that show me that it's not working anymore and to me that's still test driven even if I make 75 80 85% of the design decisions up front it's how I react when the tests are trying to tell me something if I ignore the tests I'm not dry i'm not doing test driven anymore but if I am taking the tests seriously if I am really listening to them to me that's test driven no matter how many design decisions I make up front um it just so happens that uh you know going back to the whole we we do we do have a tendency to forget that a lot of what we write is aimed at novices and advanced beginners absolutely true i think we we do this at our risk and that's why I think it's really important for us to get together at conferences and talk about not just do a yet another introduction to test-driven development uh but to talk about this exactly the same kind of sound conversation it's just nice that we're having this on a at a hangout on air so that a thousand people can watch it instead of at a pub where there's only room for 10 people around the table and only eight of them can hear us anyway um true the conversation probably gets more interesting in the pub but uh here at least we get a chance to talk about this and say there's a difference between what I teach to people and what I teach to beginners what I teach to people who've been doing it for a while and what I do myself and in a way that that we simply can't do not only in a 1540 character tweet but even in a 5,000word article yeah and so I come back to the very beginning that's why I find the whole the formulation of the statement TDD TDD leads to good design is clearly not true trivial tdd can't lead to good design is also trivially untrue both of those statements are so trivially wrong as to be completely meaningless so now the question is well what could we possibly you know I know you uh you you have there's a brain in there I've seen it working I have evidence that you have thought about this for more than 5 seconds what could you possibly have meant when you said TDD can't lead to good design obviously TDD on its own right a sufficiently determined programmer can do t can do the rules of TDD and produce we've seen it we've seen it countless times there is another ingredient but I think The sense in which TDD leads to good design is that it unlocks something in the programmer that not ever practicing TDD might not unlock it i if we really want to try to formulate it more precisely then I would say TDD is an excellent way to unlock the potential for the programmer to uh guide the design in a direction that uh that maybe doesn't optimize but approaches optimizing the uh ROI on the or optimizing some potential for return on new features in the future which is a really long way of saying without TDD we've got a whole bunch of people who uh who make a bunch of guesses up front who assume that their guesses were right when things go wrong they assume that they should stick to their guesses and the more they do that the harder it gets to to ship new features over time we have the exponential cost of features curve until we reach project heat death 17 and a half months from now which is when we fire the CTO do it all again in Python and swear we're not going to make the same mistakes this time and I think that uh without ever seeing TDD that cycle is just so much more likely to continue that I don't find it unreasonable i find it quite reasonable to say TDD stops that from happening not always not for everyone but significantly often and for significantly many people yeah for for me because I was accused uh once because there was a guy in another place that he said "I want to parry you." like I need to understand how you do this thing right so because the guy was more normally do the classist approach I normally as I said because of the line of work that I normally do I normally start with outside in and then I flip to class assist uh but he couldn't understand why I would do that and then I I start test drive and say okay so for this class I what do I expect as a result of this method invocation a few things so I will create a few collaborators that will be responsible for And then he said well but you are not using test i said well just hold bear with me for a sec test are running up here exactly so but because the thing is like as I start thinking about these things I need to write the test and all of a sudden one collaborator with a mock another collaborator with a mock a third one okay a fourth so while I'm writing so exactly the test is helping me it's not telling me what to do but it's saying "Look you made a design decision and the class that you want to test is now talking to four classes you probably are missing an abstraction here this class is probably doing Wait a second no no no hold on the test is telling you what to do." So this is the metaphor that I like to use right the test is the test is it's like a baby crying you have to the baby is telling you what to do but you have to learn how to understand the language it's speaking right the code the code is crying and you have to learn how to tell the difference between my diaper is wet I'm hungry I am bored just like you have to learn the difference between you're missing an abstraction you have too many abstractions uh you know your interaction is too complicated your interaction is not complete enough so but but that's the thing right so like a lot of people would what they would do criticize mocking mock sucks absolutely yes and that that's that's my my my issue because like if if I may I'll tell you a short anecdot right so I was speaking to my wife and a friend of mine same age coming from the same background from Brazil to the UK roughly the same time right so we spent our teen uh teenage uh like yeah we were teenagers same place listen to music and stuff we were talking about music so a friend of mine asked okay what music would you uh you you listen to when you were younger or still listen and I said I like this band this this and that and then he said how could you listen to that crap and then I said okay so what did then my wife my wife said I think and like what do you used to listen then she said I used to listen to this this and that so like both of us my friend and I how could you listen to the crowd and that's okay so what are you my friend like what music like what type of bands you used to listen to and it's like oh I used to listen this and how could you listen to crap so three people listening to music same age and each one of us thought that the other one was listening to crap the difference I like punk rock because for me music is more about lyrics i love lyrics lyrics that are protesting stuff so we had a challenging time in Brazil back then and so people punks were complain about everything so that was that's what I like to listen my wife likes to dance for her she doesn't care about the lyrics she care about the rhythm right she likes to dance and have a good time my friend on the other hand she's a musician he couldn't care less uh about lyrics or rhythm he cares about how musicians plays the instruments the techniques that they use so the reason that I always mention this story is that when you are writing test and people say you should listen to your test you should know what you're listening to that that's one of the things so you should at least have a guess of what to listen for right or listen to like okay this is what is the the this is what the test is trying to tell me and that's when I feel that because I had some design background it's much easier for me to spot these things straight away and not blame a a a library that is a mocking library right right so for me I think again the difference between the two of us is that for you I think it's the difference between uh so your your native language is Portuguese my native language is English right uh but we both speak Spanish probably pretty well i'm going to guess that you could if you're stuck somewhere in Spain you're not going to have trouble getting people to understand you it's the same for me now think about the difference between the way you learned Portuguese and the way you learned English or Spanish when you learned Portuguese you didn't know anything about language and you were immersed in Portuguese and that was how you learned Portuguese so you had to reverse engineer all the grammar rules of Portuguese from birth now when you started to learn English because there's some similarity between the grammar rules in Portuguese and the grammar rules in English you had a head start now what you're saying TDD can't lead to better design the way in which I think you mean it is almost like saying you can't learn English as a first language you have to learn some other language first and then that gives you the basis for knowing what to listen for in English so that you can understand the grammar rules but I learned English from birth i did not speak any language or understand any language before I learned English which is closer to the way I learned design though clo the way that I learned design uh it was almost like I was relearning my first language it's almost like I had brain damage and then had to learn English again um and in a very real sense I had brain damage you should have seen some of my designs um so the you know I learned I think that I think that TDD provides an adequate mechanism to discover the rules from the beginning that you already understood before you started practicing TDD um there are some principles of design that you understood better than I did at the time that we first started practicing TDD tdd helped me learn and understand those principles in a way that simply reading a book couldn't do it or let me let me say that more precisely didn't do it's possible that if I had not been introduced to TDD until 2006 it's possible that I would have learned more of what code and Jordan and McConnell and Maguire and all those guys were trying to teach me through their books but TDD made uh TDD provided me with an opportunity to understand those things at a more native level i learned them in a more native language kind of way um I think partly sometimes that's what makes it difficult for me to explain some of these design principles to other people it's much easier for me to explain French grammar to someone than it is for me to explain English grammar to someone and maybe more importantly there are some things that we say in English that I have trouble explaining to someone else why we say them that way but for everything that I know how to say in French I can explain why because of the way I learned it in French mhm and so I think that might be the difference now what you're saying really I think equates to it doesn't equate to it's impossible to learn English as a first language i think it actually means you don't have to learn English as a first language you can learn English as a second third fourth language using you know uh ha knowing Portuguese or Spanish or French or Italian has some advantages when you try to learn English or maybe even a better example is growing up French makes it that much easier to learn Spanish i found it easier to learn Spanish because I already spoke French that's true but the person who was born in Spain who grew up learning Spanish instead of Cadalan for example they probably didn't learn Spanish as easily as you did but they learned it uh they might not have learned it as easily but they probably learned it just as deeply as you did and maybe in some ways a little bit more deeply uh it just took them longer no I I think that uh of course that I didn't learn these things just reading the books of course that I definitely Right no but yeah I mean but but that you didn't need you didn't need tests to give you that feedback you got that feedback some other way i had exactly what you had i had a lot of more experienced people with me and we felt the pain together or I felt the pain and then they said "Yeah you're feeling this pain because you're doing this wrong why don't you organize your call in this way that's a much better way." Like I was always getting feedback from other people like why is this so complicated so I'm using all these design patterns inside well because you shouldn't use all these design patterns because you don't need them right so TDD helped me to definitely to to refine my design i definitely my design is much better today because CD puts an extra constraint it makes me think hard so I think okay that's the design that I have in my mind but now I have a constant mind validating that immediately but I learned a lot from other people more experienced i refined knowledge with books applying in the systems wrongly like right I have a love and hate relationship with domain driven design like I I like until today after 10 years that I was exposed to it I cannot do that properly right so I still struggle with that but there is valuable so I think that what I'm trying to say is like I said like if you know another language and you are learn a new one there are things that you can okay that's the connection yeah I've seen that that somewhere else this is just like you bring up a different way I think that my point is if you also if you don't you don't need to let everyone bang their heads their heads against the wall if if you say look there are things that you can look at so and I will teach you I'll pair with you I'll show and not talking about reading a book I'm saying like let's sit down and write code right so can you see this yeah cohesion cohesion is the cornerstone of everything in my view right so cohesion so there are levels of cohesion per method levels of cohesion it's not a binary thing is cohesive but it's not cohesive and coupling same thing there are levels of coupling and stuff so explaining these things or oh you know what there is a verb in here there is a noun in there right have you thought about using this so it's not just let what I'm saying is that it can be taught certain things so it will be easier for people when they are doing TV becomes a little bit easier because they have a guess of what to listen that that's that's that's what I'm saying it's easier to spot not what the the tests are trying to say and then we wouldn't have so many people saying criticizing TDD criticizing mocks criticizing other approach because it sucks and they are slower well maybe we should teach them TDD but also give them more information so they can use that more effectively and reduce the learning curve like the J curve will be reduced i I I think I think I understand very well and and and it leads me to to again another little idea that's kind of crystallizing that TDD then and this is now I have a great way to say this in my training classes uh which will be helpful in about a week and a half that TDD triggers the conversations it triggers the opportunities for you to ask the questions that lead to the learning tdd is certainly not the only way to do it not necessarily the best way to do it it's probably not the most efficient way to do it but I'm going to argue that because of this uh first language learning effect that it is uh that it can be an extremely um and I'm struggling to find the right term it's a it it's an extremely effective way of learning those things deeply the same way that you understand your native language deeply in a way that you will never understand your second third fourth language the there's there's some deep there's some deep connections in the brain that you just unless you learned your other languages also from birth you'll probably never have that so yes TDD alone doesn't lead to good design because you could just have the person banging their head against the desk forever and never getting anywhere because they don't they don't have people to ask they don't know what questions to ask they don't realize that they should be asking the questions uh but to me TDD leads to good design in the sense that it's really hard to practice TDD and not be forced to ask those questions and not be forced to find people and not be forced to confront these problems uh you'd have to be crazy in my view to practice TDD for more than a few months and not uh at some point be crying for someone to tell you what the is going on mhm and it's the it amazes me that anybody would think that it's the right thing to do to keep that pain to themselves to never ask for help i mean it it's that seems crazy to me it it to me it would be the same thing as deciding I'm going to start exercising and then you tear a muscle in your arm and you feel this huge pain in your arm you don't understand what the arm pain means but you keep doing the goddamn curls hey buddy put down the put down the barbells and talk to a doctor at a minimum go to someone else in the gym and say "Look I can't tell the difference whether this pain is a micro tear and that's good and I just need rest or has the muscle detached from the bone and am I in serious trouble?" Uh but if you just keep doing this and feeling intense pain I can't help you so to me the the sense in which TDD leads to good design is that it forces it makes the pain it puts the pain right in front of your face in a way that not writing tests doesn't do but on the other hand if you have another way of getting that if you're more sensitive to that feedback if you have other people around you who are more sensitive to that the pain um as long as you are not surrounded by people who have become numb to the pain over time you can get that same feedback it doesn't have to be tests it can be the one of the other people on the team looking at you and going "Gh why in the hell are you doing that?" Or it could be you simply uttering the magic words there's got to be a better way for me the difference is that tests are telling you "Hey idiot there's a better way you just have to listen." So to me imagine that you're on a desert island and you're learning to design software you can't talk to anybody practicing TDD forces you to confront these questions sooner now that doesn't guarantee that you're going to learn from it it doesn't guarantee that you will know what to do about it it only guarantees that you confront those questions sooner in a way that not practicing TDD that not writing tests doesn't do in a way that drawing diagrams doesn't do and even in a way that writing code in a trance for six hours doesn't do uh and that to me is the way in which TDD which I feel okay saying TDD leads to better design it it leads it forces you to reflect on your design and if you have any ability whatsoever to learn it will drive you there sooner it's not the only way and it's not the best way but it it works in that sense and I think and I think for us to claim that it's the only way or the best way would be a mistake certainly you can get there other ways your proof guys excuse me we're losing the attendees and I got to go for dinner so okay maybe maybe we have to gather sometime in the future again because I had a few questions for you and I guess also people had a few questions but you have been so passionate which is good um but I think it's today yeah I I'm happy to follow this up with a pure question and answer session uh later on i'm totally in for that yeah me too let's do another one just to go through the questions later on at some point so happy all right excellent excellent i'll have a with the guys they're leaving as well okay now I'm going I want you guys are in the wrong time zone man that's your problem it's only 5:30 yeah the guys are hacking next door so they're I want you to have a drink with them as well thank you welcome i'm not going to get in your way guys thank you for your time well it was a pleasure thank you for putting this together Carlos i appreciate it yeah me too it was great to see you guys thank you very much thanks for watching everyone cheers