Jim Coplien and Bob Martin Debate TDD

this is Floyd marinesko and I'm here with Jim Killeen and Bob Martin at the Java conference and here we have two very interesting divergence of opinions on what is the value of TDD so we'll open up the floor and let each one none have a couple minutes say and then let's hear you guys talk about it okay so first thing I need to say is I'm sitting next to one of my heroes I read Jim's book in 1991-92 changed the way I thought about software changed the way I thought about C++ in particular so it's a great honor for me to be here I think we have a disagreement I'm not sure possibly it may be a difference in perspective but my thesis is that it has become infeasible in light of what's happened over the last six years for a software developer to consider himself professional if he does not practice test-driven development well maybe good because you did this at your keynote yesterday you said what you mean by testing and development so you know I've adopted a very strong position against what the particular the XP community is calling test-driven development and I've audited this you know versus a lot of tutorials at gosh at about four conferences at Rosendo Gil at a dev at Q Khan here and one other in the past six months and they give a very consistent story what they mean yours was a little bit different yesterday so maybe for for sake of making this a meaningful conversation you can quickly reiterate ok so we're on the same page so I have a three laws of test-driven development the first one is a test-driven developer does not write a line of production code until he has written a failing unit test and no production code can be written until there's a failing unit test the second law is that you do not write more of a unit test than is sufficient to fail and not compiling is failing so you cannot write very much of the unit test before you must write production code the third law is that you cannot write more production code than is sufficient to pass the currently failing test so you cannot write a little bit of unit test and then run off and write a whole bunch of production code these three laws you into a cycle that is perhaps 30 seconds long and that means you're actually writing unit tests and production code concurrently with the tests perhaps 30 seconds to a minute and yeah that is my definition and per se the main concerns I have about TDD are not problematic with respect to what you just said in isolation so if it's no more no less than that we may not have a big disagreement what what my concern has been comes out of doing broad work with a lot of clients and a little bit of interactions with other consultants and other scrum masters who have seen these things happening in their project and the problem that we have seen two major problems and one is is that that use of TDD without some kind of architecture or framework into which you're working which is was very strongly Kent's original position right you use TDD to drive your architecture leads to a procedural bottom-up architecture because the things you're testing are units we just had a discussion upstairs about you know as TDD the same as unit testing well no it's a little more but unit testing was a great idea in Fortran you know when you can build these layers of api's and the units of organization of the software we're the same as the units of testing but today the units of organization of the software are our objects and we're testing procedures and there's a little bit of a mismatch now if you're using the procedures to drive your architecture I think you're trying to build a three-dimensional structure from two-dimensional data and you end up going awry and one of the things we see a lot in a lot of projects as projects go south on about their third sprint and they crash and burn because they can't go any further because if they've cornered themselves architectural e and you can't refactor your way out of this because the refactoring has to be across class categories across across class hierarchies and you no longer can you have any assurances about having the same functionality so and the other problem we've seen is that this destroys the GUI and this is what you know what Twiggy and I talk a lot about is because because you have this procedural architecture kind of in a Java class wrapper you no longer are driving the structure of the system according to domain knowledge and things that are in the users conceptual model of the world where objects orientation came from I mean even Kent as he's very often said you can't hide a bad architecture with a good GUI you know the architecture will always shine through to the interface and I strongly believe that and that's why I believe you need something in the infrastructure that gives you a picture of what the domain model is out at the interface then if I want to apply you know Uncle Bob's three you know three rules I probably don't have a problem with that but I want a starting place it captures this other dimension which is the structural dimension all right but you do not accept the thesis that the the practice of test-driven development is a prerequisite to professional behavior in 2007 and I absolutely do not okay that so we can come back to that one because I think that's an interesting topic just in the topic of professionalism but before we do that there has been a feeling in the agile community since about 99 that architectures are relevant we don't need to do architecture all we need to do is write lots of tests and do lots of stories and do quick iterations and the code will assemble itself magically somehow and this has always been horseshit that's always been heard thank you um and I even think most of the original agile proponents would agree that that was a silliness and I think if you went and talked to Kenton now he would be talking about well you know we always talked about metaphor whatever the heck that was in fact he says this in an XP explained or something his page 131 of his book he says yeah you do some upfront architecture but sure don't knock yourself out okay but now let me come back and throw a different light on this I think architecture is very important I've written lots of articles and books about architecture I'm a big architecture freak on the other hand I don't believe architecture is formed out of whole cloth I believe that you assemble it one light one bit at a time by using good design skills by using good architectural skills over the weeks and months of an iteration and I think that of many iterations and and I think those that some of the architectural elements that you create you will destroy you will experiment in the first few iterations with different forms of architecture within two or three or four iterations you'll have settled into the architecture you think is right and then be enter into a phase of tuning so my view of that is that the architecture evolves it is informed by code that executes and it is informed by the tests that you write I do agree that architecture involves evolves I do believe it's informed both by the code that you write and maybe even earlier by by use cases that come in that inform you about things are relating to scope and other relationships but if you try to do things incrementally and do them literally incrementally driven by your interaction with the customer without domain knowledge upfront you you run risk of doing it completely wrong I mean I remember one when I was talking with Kent once about in the early days when he was proposing TDD and this was in the sense of yog knee and doing the simplest thing that could possibly work knee says okay let's let's make a bank account a savings account what's the savings account it's it's a number and you can add to the number and you can subtract from the number so what a savings account is is a calculator let's make a calculator and we can show that you can add to the balance and subtract from the balance that's the simplest thing that could possibly work everything else is an evolution of that if you do a real banking system savings account is not even an object and you're not going to refactor your way to the right architecture from from that one what a savings account is is a process that does a an iteration over an audit trail of database transactions of deposits and interest gatherings and other shifts of the money it's not like the savings account is some money sitting on a shelf in a bank somewhere even though that's the user perspective and you just got to know that there's these relatively intricate structures in the in the in the in the foundations of a banking system to support the tax people and the actuaries and all these other folks that you can't get to in an incremental way now you can because of course the banking industry has come to this after 40 years not to give yourself 40 years it's not very agile so you want to capitalize on what you know up front and you know take some hard decisions up front because that'll make the rest of the decisions easier later yes things change yes architecture evolves and I don't think you'd find anyone who will say put the architecture in concrete I also do not believe in inputting the code in place that is the actual member functions upfront you put the skin you put the the rolls you put the interfaces that document the structure of the domain knowledge you only fill them out when you get a client who's willing to pay for that that code because otherwise you're violating you're violating lien C and then you do things just in time but you want to get the structure upfront otherwise you risk you know driving yourself into a corner so I would I would say that a little differently and take exception to some of it I would not very likely fill in the interfaces with abstract member functions or defunct member functions I might create objects that should will fill the place of interfaces so in Java terms I might have an interface something with nothing in it but I'm not going to load it with a lot of methods that I think might be implemented one day that's something I'm going to let my tests drive the the requirements drive and I'm going to be watching it like a hawk to see if there's any kind of architectural friction friction that would cause me to split that interface but the problem is is that's like that's like saying that words have meaning apart from any definition and so the fact that I call something a mule you know without saying what a mule is doesn't make it a mule like Abraham Lincoln said you know calling a mule and ask doesn't make it one and so the thing that gives meaning to stuff is the member functions the semantics now yeah you don't want to go crazy and you don't want to go into you don't want to be guessing and here's where I agree with Kent he says in the XP explained book he says you don't want to be guessing and that's true but I do want to assert what I know and there's some things you just know about the structure of a telecom system a banking system you know that you don't build a recovery object I was on a restructuring project in in a large telecom company once where they were redoing a toll switch and using object-oriented techniques and modern modern computer science techniques and I got assigned to work with a guy who was making the recovery object well this is ludicrous recovery isn't an object but yet his superficial knowledge of the domain led him to that now if you get down to understanding what the member functions of that are then you'll see this isn't even an object so you ask well how do I know it's not an object well what are its member functions uh to recover well okay great that's that's a lot of help actually I think there's people who've capitalized on this in the South called sowa what that's the danger you want to have something there to give the object meaning okay and I would even agree with that you need something there to head to to give the object meaning I'm going to be really minimal about that me too okay good ol disagreement good and then I'm going to let executing code inform my future decisions yes so I'm not going to create a massive architecture or a huge system based on speculation that's right oh no disagreement all right so back to the beginning how long would you spend before you started writing executable code on a oh let's say it's a system that will eventually wind up being two million lines of code so two million is in my experience pretty small now I'm working with hundreds of millions before the first executing code so I don't know it depends a lot on the individual system but let's say I were building again a simple telecom system what I would probably do let's say I'm doing it in C++ telecom systems you often are I would have at least constructors and destructors in place and be able to start to wire up important relationships between the objects and that's the test testing those worries I would have testing do tests for those wires yes okay all right make sure an obvious test is to make sure when the system comes up and goes down that the memories clean for a temple great ah half an hour excellent okay so where is our disagreement perhaps our disagreement is on the notion of TDD and professionalism so that was the second time that was the second yes the second part part I think that's a separate disagreement yes okay fine well maybe we can put this one to rest this is nice okay but I mean the thing almost here there must be a make up the audience is is that again I think that when I'm running into people who are doing things right that avoid the kind of problems I talked about earlier it's not tdd out of the book or are tdd out of the box so people have found a way to move to what you know what Dan North Mountain now calls BD D right or example which i think is really cool if you ignore the r-spec part and all the stuff works which is kind of dragging it back to - too low of a level so there's a lot of people doing the right thing and my concern is is they're calling this good thing TDD and then people are going to buy books and they're gonna look up TDD and they're going to find this this old thing which is architecture only comes from tests which I've heard four times and tutorials in the past six months and that's just it's like you say it's horseshit yeah okay but now on to the professionalism okay yes all right how do you how would you know a professional if you saw one they practice TDD um professional to me is just someone who makes money for doing a job in that area yeah no I'm gonna push push on that one because I think that something our industry has lacked is a standard of professionalism I'll take we'll take your definition as a starting point that we can talk about that okay well that's not actually my definition I was joking I think that nowadays it is let me rephrase it it is irresponsible for a developer to ship a line of code that he has not executed in a unit test and one of the best ways to make sure that you have not shipped a line of code that you have not tested it is to practice TDD yeah and I do disagree with that okay now I think there's something deeper that is important and let me let me let me attack this by example as an example of something I could do as an alternative I could wave my hands and say a lot of things about code inspections or pair programming and those are good and probably have more value but it's kind of an independent discussion but let me give you something that I think hits the nail on the head even more importantly and let's look at what what a unit test is what a unit test does is looks at an API of a procedure and kind of goes and hits the the state space of the arguments and you know maybe hits a half a dozen of them or a hundred or a few million of two to the thirty second or two to the whatever and so you're just you're you're just doing hit and miss and yeah that's that's really really heuristic and you got a really lucky to find bugs doing that what I think is more powerful is designed by contract so you have preconditions post conditions and invariants now the technology isn't there yet in most languages they haven't matured to the point where eiffel has where you can statically check these things but you can build additionally you know additional infrastructure to do that kind of thing I think it has all the advantages of TDD there are these advantages I'm supposed to advantages but I'm going to think hard about the code you know I'm going to focus on the external view and so forth and I have found at least for me that contracts do that more effectively than tests do furthermore they actually give you broader coverage because you're covering the entire range of the arguments rather than just you know randomly scattering some values in there now Bertrand Meyer has actually taken this further and he has something called CDD which is contract driven development where what he does is he takes contracts and he kind of feeds random numbers at them and you know if they don't if they don't meet the preconditions you don't run them because you know that test will fail but you test that if the post conditions hold after you run the test and if they don't it's a bug and they've actually done this they have a tool that automatically runs tests they've done this on the eiffel library and they ran it about a week they found seven bugs in the 20 year old eiffel library now that's kind of interesting but it comes from a part of the code where you're expressing intentionality in a way that has hope of being traced back to a of something of business importance and the problem about TDD is most people practice it down at the class level is it's really really difficult to trace those those api's at a class level sometimes all the way up to business significance so I'm having trouble with that as I remember eiffel and I thought this discussion was put to bed a long time ago as I remember eiffel and design by contract you specify preconditions post conditions and invariance around every method yep and around your class well the invariance in the class variance or the class yeah test-driven development or a suite of unit tests virtually does the same thing it specifies a set of of incoming checks on the arguments outgoing checks on the return values explores the state space as you said of the of the methods so I always thought that they were they were one-to-one you could you could always transform contracts in the unit test or always transform unit tests into contracts with the exception that the direction of the dependencies is different and you know I'm a big dependency freak yeah unit tests depend on code on production code which i think is good production code doesn't depend on unit tests whereas contracts are smeared through the code which bothers me well I think you're creating a dualism that needn't be created is that there is one thing which is the code the code is the design it's what's delivered anything else is is not lean if you have in typical projects that use unit testing the code mass is about the same as the test mass and where's there's code there's bugs you cut your velocity in half there's there's well-known examples I mean the most famous example is ADA compiler where actually use of test-driven development increased the number of bugs in the code because your code mass increases because you have more tests if you're using assertions you have this nice coupling that's essential coupling between the semantics of the interface and the code itself whereas that you know the tests the coupling is a lot Messier and hard to manage so there was another point you had made it was going to react to I'm surprised that you think the code mass is different and it's experienced in my experience it is if I look at how people actually use this I like it when I see a inspect that looks like assertions but a lot of the time it isn't well okay and that's not I agree with that there are message okay but there's messy code yeah I you know I don't like arguments that the tool is hard is easy to abuse therefore you shouldn't use it invalidated all there is that isn't my argument my argument is how I'm seeing this being used in broad practice and sure they're not getting it well okay all right and do you see contracts being abused in broad practice and well first of all they're not I used to know okay right by the way um since we've just got a couple of minutes left just a trivia question and I don't know the answer um who is it that first used Dede with some letter in front of it you know we've got C D D now he's got BD D we've DVD we get I don't know what else in the earliest one I can remember is Rebecca whoops Brock responsibility different design was there an earlier one oh so not even driven development to the driven design or D V DD what was the UNIX command to do dis stuff that probably doesn't count thank you bye good seeing you again

Channel: toalexsmail

Views: 130,866

Rating: 4.9414086 out of 5

Keywords: TDD, BDD, DCI, OO, programming

Id: KtHQGs3zFAM

Length: 20min 58sec (1258 seconds)

Published: Tue Oct 23 2012