Slashdot Mirror
Test-Driven Development by Example
What it's all about: Test-driven development is about being able to take tiny little steps forward, test that the step took you in the right direction, and repeat. The "TDD Mantra" is red/green/refactor:
- Red: write a test which will exercise a feature, but which will fail (because you haven't yet written the code)
- Green: make the test succeed, doing whatever you need to do to get to "green" as quickly as possible -- don't worry about prettiness
- Refactor: now that you have code which passes the test, eliminate all the duplication
The book then shows 2 fairly detailed examples of a development project (or snippet of a project) which progress using this style of coding. The first example deals with the creation of multi-currency capabilities for an existing project. In the space of 17 chapters, the author walks you through the creation of 6 classes (1 test class, 5 functional classes), complete with the thought-processes behind them. The code is written in java, and is trivially easy to follow, because it gets introduced in tiny little chunks; most chapters are less than 6 pages in length.
The second example is the creation of a unit testing framework in Python. It is significantly more complex and real-world than the first example, but again proceeds in very small steps, and in small chapters.
The final part of the book contains patterns for test-driven development -- practical real-world advice on how to do this stuff for real. Nearly all the "patterns" are phrased as question/answer pairs, and they range from deeply technical design patterns to advice on the best way to arrange the furniture.
What's good about the book? Kent Beck is a very good writer -- his writing is clear, he is not afraid to leave out stuff he assumes you can guess for yourself, but when he does go into detail you feel it is necessary to get the big picture, rather than mere geek bravado. Even if you don't adopt Test-Driven Development, many of the ideas are well worth considering for your day-to-day coding situations.
What could have been better? The book stresses the importance of taking 'little steps,' and sometimes you feel impatient to move to more challenging tests before properly finishing the current chapter. I was also hoping for more of a discussion on the practicalities of unit testing database-driven systems, where you frequently have to test business entities which are closely coupled to the database.
Summary If you code for a living, or manage people who do, you should read this book -- it's a quick enough read -- and consider some of the assertions it makes. If you feel you're introducing more bugs than you expected, if you feel uneasy about how close your work matches the requirements, this book gives you some powerful ideas. You can purchase Test-Driven Development by Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Although it sucks to lose 20% of your code when you drive it off the lot.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
I don't like ESPN's eXtreme Programming, but now that the NFL is over, I don't have much of a choice.
hopefully, this will last as long and have as big an impact as extreme programming did.
for the sarcasm impaired : this is sarcasm.
... hi bingo
Once my manager came in with the buzzword eXtreme Programming. I read a couple of articles, I tried it but what a disaster. I just can't stand other people nozing around in my half completed code, the extreme attention to testing and the team-spirit you ought to have. Needless to say the experiment failed and things went back to normal :-)
/(bb|[^b]{2})/
I think we must try to get rid of wanting to design and plan every little thing in front and then find out stuff doesn't work ending up running out of time and in the end having noone willing to pay for all useless efforts.
Although many people don't believe in XP it is a way to accomplish development in such a way you do get deliverables. Maybe it does not improve speed but it does improve quality and reduce risk.
So any book which is able to explain the pro's of XP and open eyes of non-believers is good.
giel.y contains 2 shift/reduce conflicts
The reason some XP projects are successful is because they actually have testing as part of the game plan. It is *shocking* to me, having been in the industry for better than a decade and pounding code for 20 years, the state of testing in corporate america. Just atrocious.
There are many labs that don't test at all, and a vast majority test poorly. I've worked in some fortune 500 labs that didn't test at all. Scary stuff. Nothing life threatening, but all of a sudden I wasn't so convinced that the reason my account was misconfigured was because *I* gave wrong data. Simply bug riddled. Those that do test often do so manually. Forgetting for a moment that humans are likely to take short-cuts and not bother to execute tests they perceive to be out of the scope of their recent change, they are failable. Of course they are, that's how the bugs got there in the first place.
So, the XP folks have the testing thing down. They test before the code is written, and their tests are automated.
Then they take leave of their senses. The claim that because they've successfully turned one idea on it's head (i.e. testing *first*) that they can turn others is ludicrous. Design first is still valuable guys. I've eliminated thousands of bugs simply by having the right design to begin with. Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser. If it weren't Scott Adams wouldn't be a millionare.
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
poliglut.org: they're still alive and fighting the man
it would be nice to have 2 developers for every problem... but that is never going to happen.
...been doing this for years anyway? My code development cycle has always been... 1. Write code to use function/procedure. 2. Write function/procedure. 3. If function/procedure==fucked return to 2 and unfuck. 4. Once it works, tidy it up. Now it appears someone else has added steps 5 and 6... 5. Write a book about it. 6. Profit!!!
What would Dilbert do?
Here and here!
I love buzzwords with X anyway..."There is no teacher but the enemy."-Mazer Rackham
You can get Martin Fowler's "Patterns of Enterprise Application Architecture" in a bundle bargain at Amazon along with Kent Beck's "Test Driven Development" for $79.98 [link to PEAA bundle]
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Does the reliance on incremental development and refactoring rather than a intricate, up-front design really work, or result in a big wad of band-aids?
Is pair programming OK, or do you sometimes get stuck with the nitpicker from hell who has to have every detail his own way?
Is close involvement with the customer good, or does it just give them daily opportunities for endless bright ideas that prevent convergence?
Just wondering...
Isn't that the whole crux of XP? If you're not organized, nothing will help. If things are organized, but need tweaking, then XP can be beneficial. Having the pre-requisite of having some organization to how software is developed is the hardest part. If your PM isn't organized and you're not organized, forget about it. If you're organized, then you're probably already doing unit testing in some form.
The idea of breaking your program into small parts and testing them is fine. Writing programs to test these parts seems to be a bit problematic. I wrote a test program to test this module. But then I remembered that I forgot to write a program to test the test module! You use your specifications to write your module, then you test against these specifications. If you write a program to test these specification, then you already must have a firm grasp of the specifications. What assumptions about your module are you making when you write your test? Or is this a simple black box type test where you do not care how it works inside? Any faults that you have in your conception of your test program will be carried over into your module, or worse your module might be correct but your test program flawed. Seems like an extra layer of complexity rather than a useful method. I also dislike the do it dirty and fast, then refactor part. Proper planning and implementation seems the better approach to me. I understand that "mad hacker" instinct to dive in and code away, but that has to be restrained a bit when the complexity of the problem rises.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
The Unix Philosophy
The RIAA issued a press release saying that they are initiating a lawsuit against Kent Beck because eXtreme Programming principles could lead to faster development of file-sharing software. The RIAA's main argument is that CD sales are falling at levels that could only be explained by eXtreme Programming.
That's why I've moved on to XXP, which focuses first on correctness of tests. First, I write a test that tests a test. Then I write the test. I test the test until the test tests ok. Then I write a test for another test, and so on.
My pair programming partner is currently working on an idea he calls "XXXP". I'll post our results if we ever finish a project without getting lost in infinite recursion.
Okay- this is a bit off-topic, but thought someone here might have some experience with the unit test stuff inside of Boost.
I'm wondering if anybody has used the Boost framework for something more than a toy program. It seems well though out (like all of the stuff in Boost), but I just don't have any experience with unit test stuff. I have nothing to compare it to.
-ec
Do they even consult?
seriously the percentage of projects I've seen with features that don't work because that's what the client asked for. Or are poorly put together is amazing.
You can't test if you don't have a design to test against. You can't design if you haven't consulted the requirements.
thank God the internet isn't a human right.
In my experience, extreme programming was invented by/for programmers who hate designing and discipline, and just want to start hacking. It leads to sloppiness and half-finished code, and it's not a scalable approach for large projects. I had the misfortune of having some guys on a project who insisted on working this way, and we had a huge mess to clean up in their wake. I'm glad this programming philosophy seems to be dying out.
I'd be the first to admit that XP offers a lot of risk-reduction -- for teams that are working on things that are easy to unit-test.
With a class that is supposed to take in a bond and output the yield curve, it's easy to write a unit test. But what about the next class, that renders the yield curve on the screen? What about the complex, distributed system of Excel objects and forms things that draw a network and things that flash green and go 'ping' to indicate a change, that are equally necessary but generally much harder to write and much more likely to go wrong?
Has anyone tried to apply test-first programming to complex guis? I can't say that any obvious way to do it has ever occurred to me. Worse yet, when I ask I generally find that people either
a) Are in the same position as me, or
b) Believe that a GUI is a little thing you spend a couple of days on after you finish the application
So, for now XP is something I read about rather than something I actually do.
Whence? Hence. Whither? Thither.
Last I heard, the Chrysler Compensation System was not finished, scrapped prior to going into production. What are the more recent projects that demonstrate how well XP works?
eXtreme Medicine.
Your feeling I'll, so you pop along to the doctor.
Hey Doc, I have a problem can you fix it.
The Doc has an Idea what's wrong, could be complicated, but:
throws a load of drugs at you
does a some tests, your a bit better but, well have some nasty side affects.
Changes some of the drugs, and gives you a few more......
In the end, your sort of all right, but a drug addict, and occasionally have to go back and get a different fix from the Doc.
Not-so eXtreme Medicine.
Your feeling I'll, so you pop along to the doctor.
'Hey Doc, I have a problem can you fix it.'
The Doc has an Idea what's wrong, could be complicated.
I'll put you on some light medication and get an appointment with a consultant.
The consultant comes along, has a word, still not sure, advises the Doc on some better medication gets in a specialist for one of you conditions.
The doc treats most of you conditions, and some have already cleared up.
The specialist takes a look at you and give the Doc some more advise and training.
After a few months you in perfect health.
thank God the internet isn't a human right.
I've never really tried the official XP methods, but I have had a couple experiences with some of the ideas of it, like when I'm coding when my brothers or "programming literate" friends are around. My general conclusion is that it works pretty well, you don't make as many mistakes when first typing your code and they make it easier to find problems when you do make mistakes.
I don't know whether it is truly more practical than two separate individuals programming, but it does feel more productive and more enjoyable, it's like you hardly ever get stuck on anything.
The thing is, like I said I've only done it with my brothers or friends, people I generally get along with. I could easily imagine my great experience with it turning into the programming project from hell if you don't like the person you're with.
What? Is he going to write a book for every rule of XP?
Testing is important, but XP testing philosophy is a catch all for actually thinking about your product and the purpose of you product. XP is about making hack programmers look legit. XP has some good points, such as an emphasis on simplicity, testing, and customer satisfaction, but mostly it's about making bad habits look good, like no design and iterative feature hacking with ignorance to the bigger picture of the app.
Some design up front is important. Documentation is important. Code ownership is important to an extent. In a medium to large system, having everyone able to change any line of code is just stupid. People change shit and don't have a clue why the code looks the way it does. One of the arguments for no code ownership is that a lead architect can't keep it all in his head. Well, what about a team of that consist of many folks that aren't as capable as that lead architect? they are able to comprehend the whole system according to XP. And, they are allowed to change whatever they want, when they want. So, get a couple of average programmers with large egos, and you have a lot of problems.
XP is great for people who are happy doing bug fixes all day instead of avoiding the bugs to begin with. The assertion that XP results in less bugs is pure speculation and from my experience, a very misleading claim. Just because your test succeeds doesn't mean that your program is correct. And if the test is the only glue validating the success of your final solution, you're screwed.
It sounds to me like this is just another way of designing, but that makes the wrong emphasis. These tests sound a lot like low level use-cases. You should be creating those anyways. But you should create all of those first! Not one at a time as you code.
There's trouble in a far off nation
Time to get in love formation
Your love's more deadly than Saddam
That's why I gotta drop da bomb
-Party Posse
Requirements are the Achilles heel of XP. Without rock solid requirements, you are just guessing for the test scripts.
Take a trivial example -- an entry form for a phone number. What is a valid phone number? Add in real world things like extensions, folks using alphanumeric substitution (1-800-DISCOVER), and internationalization and it gets interesting. Now a test driver is not that big of a deal if you know what to put in it. From a design standpoint, it would really be nice to have solid requirements and test scripts that provide concrete examples as to what the business was asking for. Real world? I could only dream for mediocre requirements that might resemble not only what they asked for, but what they want.... At least enough to try and read their minds.
+++ UGUCAUCGUAUUUCU
OK, so developing automated unit tests, possibly even before writing the code that will be tested, is usually straightforward and almost always a good idea.
But how can anybody design automated integration tests for applications that are intended and designed to have pseudorandom behavior, such as interactive entertainment software?
Will I retire or break 10K?
here, [pdf,yahoo.com] with more information here[vt.edu].
I've done a little test-driven development on my own.
Test-driven development seems to call for a series of baby steps, each corresponding to a unit test case. Unfortunately, I wasn't always able to identify "the next baby step"; even if I could pick what I thought was the next unit test, I sometimes found myself spending far too much time, and writing far too much code, for just that next test.
I also sometimes found that "the next test case" already passed. I don't know if I wrote more than I needed to early on, or I picked the wrong next case, or if there's more to all this than I've picked up.
When I was in good TDD mode, I was flying; test, red, code, green, refactor, green, next! It's a very rapid, and very intense, experience. There's a reason XP usually calls for a 40 hour week; by the time you're done with a few hours of this, you are tired! (But you've gotten a lot done.)
Stupid job ads, weird spam, occasional insight at
MarathonMan Brought to you by your good friends at ThoughtWorks.
pooptruck
Actually, I think that refactoring roots itself in reality. A greater percentage of the time a programmer (as a consultant or newly hired employee) will be brought into a situation where there is an existing application. Generally there isn't an option to redesign an entire application without costing the company more $$$ than it would like.
Better Design is perferred, but it is not always a reality in the workplace.
Realy! Who will care today about all those boring things like FSM analysis and formal task description! Who needs deep understanding of what his/her software does, when one just can test small part of it!
I just want to emphasize following simple thought: one may invent new perpetuum mobile without slight undrstanding of physics. And those invention nowdays aren't even considered anymore.
Computer science is matured enough to be utilized in everyday work. One have no need to study another perpetuum mobile invention guide. Just remember you classes.
I hope that in my lifetime analitical computer science will take its place in program developmen instead of witchcraft spells.
I just want to ask those adpets of XP: how you will ensure that small change in the code won't affect quite distant code parts?
I'm not a brake. I'm an accelerator. Just a slow one...
http://http://www.softwarereality.com/lifecycle/xp /case_against_xp.jsp
In two minutes I was able to save both myself and my company many man-years and headaches.
I'd already written an engineering requirements document which we reviewed with management and our partner company on the project. I've already put together an architecture document showing all the major components and who talks to whom (reviewed with the dev and QA teams). My manager even insisted that I write a design document on the specific module I was about to write, which included a schedule and unit tests.
After two months of documentation I was desperate for a chance to code. TDD? Why not. I gave it a try -- not in nearly the detail the book mentions, but I have a dozen tests each hitting a key requirement of the design. When I recompiled the code for the ARM hardware, it was gratifying to see that everything still worked on the target platform. Every time we make a change, we have the initial tests I wrote to make sure nothing is broken. It's nice.
I'd like to make the junior guy's do this -- at least then I can tell how far along they really are. "Oh, it's 80% there!!" Sure, show me the test cases that pass and how these relate to the requirements and design.
Don't ask me to pair program. I'd rather write docs and review them with the team and do code reviews.
BTW, I didn't like the book that much. But the method is good.
I am an OS developer and I am an extreme proponent of developing using extreme programming as my development method. I have three tests that I have set for myself. I have to be able to run GCC with correct output and with good efficiency (relative to Linux). I have to be able to run XFree86 with correct output and with good efficiency (relative to Linux), and I have to be able to run KDE with correct output and with good efficiency (relative to Linux). Also, it has to run all those tests on an 8 processor test machine using all 8 processors of the machine.
Anyway, I can come up with lots of tests (I do have lots of tests!) but the XP thing just doesn't work... most of my bugs are things I wrote months ago that are tripped by some odd race condition.
Also, KDE seems to crash all the time. What is the XP-complete thing to do about this?
I work for a largish (the largest?) media organisation in the world cutting code as part of a team of 4 developers plus a senior developer.
We've been using Scrum and Test Driven Development for about six months now, and there is NO WAY I'm ever going back to writing code without writing tests first.
Scrum (see http://www.controlchaos.com) is a "lightweight" development methodology. It's developer driven (no more gannt charts !!!!), and it's agile, meaning that it embraces change throughout the project lifecycle. I can highly recommend it. But I digress...
Test Driven Development is something that every halfway serious programmer should be doing IMHO. It doesn't replace the initial back-of-a-fag-packet design stage, nor does it stop you designing elegant and effective architectures. What it does do is:
So I can recommend TDD. Check it out. By the way, we're coding mainly in python with some java thrown in too.
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
So many projects don't even get completed and this is mainly because management will not accept realistic estimates as to how long they will take to complete so the timescales get shrunk and funnily enough, the project runs over. Once the time pressure is on, quality goes out of the window because it is more important to deliver.
Cynical??? - Maybe, but I have seen this happen so many times and yet no-one ever faces up to the fact that poor estimates are the root cause of most failures. If it can't be done in time, DON'T DO IT. If it must be done, allow sufficient time to do it properly.
Still, I'm only a software engineer. What do I know about anything.
harrumpf.
First of all, note that I'm not knocking the principles of Extreme Programming (XP).
The first XP book written by Kent Beck reads like a self-help book. If you're going to write a book whose principle is "feel good about yourself," and you're trying to fill 200 pages, then you can't just cut to the chase. You have to ramble on for a few chapters about what you're going to say, and slowly let out bits of information here and there, then there are chapters the reiterate what you've already said. Beck's books--and all of the books in the XP line that I've seen--read the same way. You could explain XP clearly and concisely in a few pages, but the XP books go around and around in cicles, and after a while you're not sure if you're getting new information or not. And, miraculously, the XP line has been extended to six or more books, each of which goes over the same small bit of information in another verbose and rambling way. There's even a book about XP critcisms, which is an officially sanctioned book in the XP series, which exists simply to reinforce the basic principles of XP.
The whole thing smacks of books like Dianetics or various lightweight volumes from self-help gurus. If there was any meaning to XP, it has been lost in endless self-justification. Imagine an entire series of books that did nothing but tell you how cool Linux was. What's the point?
Any faults that you have in your conception of your test program will be carried over into your module, or worse your module might be correct but your test program flawed
In practice, this isn't really a problem. As long as you write your tests first (rather than hacking them together afterwards) then they're a pretty good expression of what the code should do. Then the code itself is an expression of how to accomplish that.
Of course, it's possible that one has the wrong idea and makes the same mistake twice, but you use other practices to guard against that.
Seems like an extra layer of complexity rather than a useful method.
Maybe. My score for the last year or so is less than one reported bug per man-month of coding. And it's lower than that for my code written while doing pair programming.
I spend almost zero time hunting bugs.
This appears at first to be a trivial observation ("who will test the testers?"), but you're right on the money here. No spec is thorough enough to explicitely detail every possible scenario, and you just aren't going to consider situations in writing your test app that didn't (or won't, in XP) occur to you when writing the module.
The best solution that I can think of (and it's still far from ideal, as it takes manpower and is only statistically more likely to find bugs) is to have many test apps written by many different people, all based on the spec.
Especially with multi-processor systems, you need a solid design. Design errors here will kill you no matter how much testing you have. Generally, thinking of the tests will help you flush out your design. With a multi-threaded / processor situation, you have to know that you have no race conditions or deadlocks. Tests only say, "for this run, nothing went wrong" you need a design that says "for any run, it will always work". Review the design with others as these can be hard to spot. Once you have a good plan, you have better tests to help ensure you deliver on the plan.
Here's an idea: design projects so that they're testable! Yeah that's right design components and subcomponents so that they can be tested! This is the biggest problem I have found when tackling any project. Developers are always thinking in terms of quick and dirty solutions delving straight into implementation details without paying any attention to architecture
The fundamental problem is that most folks aren't thinking in terms of testing and architecture. I'm not convinced that the XP method works. Actually, after having read the case against it, it seems counter-intuitive and plain annoying. I'll say this though, XP is onto something by placing such a strong emphasis on testing. The first question on every developer's mind should not be "How can I solve this problem?" but "How can I solve this problem with a testable solution?" The project architecture should be subsetable and the only way to achieve that is by designing each piece of the total solution to be testable.
A project I'm currently working on has a portion of the team building a GUI enabled, unified test suite for testing the many components being developed. The developers in turn are making sure that each component has an interface available so that they can plug their components into the tester and test them. Not only can the developers test their own code with confidence but so can their peers without having to look at code written by someone else.
So far it seems as if the effort being invested into the dedicated testing environment is paying off...
Most of the time software is bad because in experienced college grads nto trained in testing are hired to code out a project...win3.0 through win95 and winNT3 to winNT4 are good exampe sof that approach..
Paired programming starts with the HR department when they hire programmers for a project in that one should hire 7%5 exp in solving that exact or similar problem and 25% inexpericed in that area for that specific project..
But most companies as you may knwo woudl rather save short term costs and vastly increase futre costs rather than do it right the first time..
Contrast the with OpenSource OS efforts where testing is a standard processs simply because it gurantees it will compile right on very lean sub standard machines that this group tend s to have access to do their work..
The reason why HP and Microsoft and Cisco went to India to recruit and staff coding centers is because they understand testing jsut as OpenSource does...
How to chgange in the US? Volunteer to be an informed Software Eningeer speaker at your local univeristy..speak and instruct the new CS students on testing...
Don't Tread on OpenSource
Actually, test-first development tackles this case specifically. You write the test first - which has to fail since you haven't written the code yet. (Technically, it even fails to compile. You then create stubs for the methods you call so that it compiles.) This is the state known as "Red". If the test passes when you first create it, you know that you have a bad test.
Once the test fails, you then write the code so that the test passes. This is the state known as "Green".
In practice, I do find that I occasionally write insufficient tests - which means that bugs get into the final product. But once a bug report comes back in and we find the problem, the first thing we do is write a test that fails (ie, back to the red state.) Then we fix the bug so that we move to the green state. And voila, we have a regression test for that particular bug.
Extreme Programming was eating Taco Bell and coding at the same time. /rimshot
This space for rent.
Here's the thing in a nutshell as I see it. Up front design is not outlawed by XP, but the XP theory is that you can go faster if you skip it. More importantly if you have a big up front design you are likely to be more likely to stick to it, even when you realize that real life is different from the assumptions that you based your design on. You will then start living with adaptations and local fixes and your code starts growing these tumor-like work-arounds that will eventually kill your ability to maintain the code.
The really important thing in XP is that there is zero tolerance for bad code and incomprehensible design. Once it is realized that something could be made better another way it is changed to be that way. The automated tests greatly facilitate this.
I sometimes found myself spending far too much time
Generally my unit test code writing takes about 100% - 150% as long as my production code writing. However, I spend almost no time on debugging. I find 95% of the bugs that would otherwise make it to the QA department (or worse yet, production) while the problem is still fresh in my mind. Usually it's caught and cleaned within a few minutes of when I write it.
Try not writing any unit tests on a fairly isolated chunk of code sometime. Then keep track of your debug time on that class for the following six months.
and writing far too much code
The more you write unit tests, the quicker you will become at laying out test data. You may also want to look through the constructors of your production code - sometimes this can be an indicator that it would be worthwhile to simplify the construction process. If it's taking you a bunch of lines of code to get a test-worthy object when testing, it probably takes a bunch of lines of code to get a usable object in production.
That said, there are some objects that are just a hassle to create a sample of. For those, I grit my teeth and get through it by reminding myself how much worse it would be to have to debug it after it's in production, with the customers at a standstill and my boss pacing a groove in the carpet.
I also sometimes found that "the next test case" already passed. I don't know if I wrote more than I needed to early on
My first test for a given class usually fails with a "cannot resolve symbol" because the class doesn't exist yet. I also occasionally go back and intentionally break a class to get the test to fail, because I want to verify that the test itself is actually testing something (prevents you from having to write a test class for your test class: Monkey, MonkeyTestCase, MonkeyTestCaseTestCase, MonkeyTestCaseInfinity, MonkeyTestCaseInfinityPlusOne...)
Stop-Prism.org: Opt Out of Surveillance
I worked at a company that decided to do exclusively Extreme Programming. They even hired an extreme programming coach whose name I won't mention but would be recognizable to some people. We had tons of problems as I see it but the manager likes this way of doing things so they are doing it until their VC funding runs out. I found XP to have quite a few problems.
1) Lack of planning
We didn't plan and ended up redoing things over and over. There were things we (the experienced people) knew well ahead of when we had to do them. Things that were self evident from day one and other things that a half decent architect would have recognize as needing to be addressed right away. Hoping to refactor things all the time is nuts since it ends up chewing up tons and tons of time. Writing what was suppose to be a "server" without taking into account multi-threading and more than one user was an example of this.
2) Lack of code ownership
You can?t ?fix? something when you don?t own it. The funniest example was our battle with the coach. He changed something that was working fine. We found lots of bugs in it that were a result of refactoring. We decided to change it back to a previous version but included a comment in the cvs log saying why. He must have gotten pissed and checked it all back in including the bug. Idiotic. People make mistakes and never correct themselves because there?s no feedback since they don?t live with their mistakes. Other people ?fix? it. Sometimes it?s not broken but simply a different solution to the problem. This is best called battle of the microarchitectures. The code doesn't get finished.
3) Pair programming
This was so tiring. Watching someone make mistakes and correcting them is boring. It?s worse almost for the person making the mistakes because they get constantly corrected even when they are in the middle of formulating stuff and just moving things around. It?s very tiring. You cannot force anyone to make a change because if they disagree they just keep doing what they want if they have the keyboard. How long can you complain before you get tired. If someone lives with their mistakes and corrects them fine but why have someone look it over. I didn?t see the quality of the code being any better than before we did do this stuff. In fact it tended to get worse because we were so bored we started making more and more stupid mistakes.
I'm not necessarily discouraging XP. It's great. You can actually slack off much more than in a regular shop. There's always your pair to blame and since no one owns anything there's no one to pin something on. The coach even admitted when interviewing someone that XP doesn't lead to producing experts since the knowledge is distributed in the group and no one concentrates on any particular thing.
The tests are a total joke. Since people want to test every method we have very little private methods (read encapsulation) because you can't test a private method from another class. Since it's expensive to do the set up for a method and we are testing a thousand or more methods a lot of methods are simply public static (we are doing Java BTW). Since everything is tested you just end up throwing away tons of tests every time you realize there's an easier way to do things. Some times you say to hell with refactoring something since that would mean changing tons of tests.
I totally hate working at this company. It sucks big time. Our code looks like spaghetti. I've already decided as I look for a new job that I will not work for an XP shop again. I'll consider another agile shop with an architect and some thought out plans for an architecture and testing.
Some of the comments I read in the "software reality" web forum that defend XP sound a little... well, defensive. One comment made it sound more like a philosophy than a set of measurable practices. I also sensed in the "case against XP" article that the author feels that XP's defenders can always say "Well, they didn't implement XP in the way that Marx^H^H^H^HBeck intended, so it doesn't count!" just as supporters of Communism sometimes said about Marxism(TM).
I think the "Case Against XP" makes a lot of valid points. Who can afford to continuously refactor 100KLOCs of C code for example? It's hard enough keeping up with the integration issues with a stable code base. You want code rage? Try breaking a few dozen test cases by making "improvements" to your design that ripple in all directions.
One important point about "Case Against XP" is that it may be criticizing radical forms of XP that might not exist in practice. A little slack might be warranted if XP projects in practice do not actually churn the code base as much as the religion might expect. And the author makes fun of Beck for excessive optimism, even as he exhorts the effortlessness and elegance of "getting it right the first time"... yea right.
So yes I'm a critic of XP, but I'm also a critic of ~XP.
If you meet the XP {booster,critic} in the road, listen to him but don't follow him... chaos and madness may await you as surely as dereferencing NULL. You must find your own way on the road, grasshopper.
Write a bunch of code that possibly does something like you think you or the user wants. Let someone else try it out, then fix what they complain about.
I'm only partly joking. When the requirements are vague, this actually works.
I've been doing this for 10+ years... it's the best approach for coding there is. It may not look pretty, but hell .. it works, and it works a hell of a lot better than any of my competitors' software ever will.
This is kind of like that joke: "Doctor, it hurts when I do this..." Seriously, avoid, where possible, coupling your classes (even persistent ones) to a database. The fact that you're having trouble testing these should tell you something about the quality of the encapsulation in your system.
It certainly was an eye-opener for my development team. We were working with an implementation of the Data Access Object pattern (Service class +value object + DAO = persistent component). What we found was that the further we got from the database, the more we were repeating tests. In other words,test that DAO can retrieve, test that it can write. Then test that the service can read, then that the service can write, and go check the database. Set up and tear down was a major pain, and only got worse, until...
We figured that we couldn't be the only ones to run into this issue. We started digging around the Wiki Wiki Web to find suggestions for how to factor our classes properly to make them easier to test. We turned up the Mock Object pattern. Basically, have the DAO implement an interface, then implement that same interface in your test. You now have a well factored class, and you can do setups and teardowns of data that doesn't exist.
Handling related instances is difficult, but that leads to the next refactoring... a domain model architecture with a service layer on top, and a o/r mapping layer underneath. But that's another story.
I did about 6 months of XP (all day team programming included). Some comments:
"Test First" helps more than you can imagine without trying it. Our rule was "no code is written unless it's a fix for a broken test". This saves all kinds of time wasted on grand schemes, frameworks, APIs, etc. - you're forced to write what you need, *just* what you need.
By the time you've written the tests, you understand the problem a lot better than you did when you started.
Having the tests gives you the connfidence to refactor. When you can test *all* your code by running the hundreds of tests you've built up over the course of the project, you'll never again hear (or say!), "I'd like to imprive module X, but I'm afraid I might break the system."
I'd encourage anybody to give "test first" a try, even if you don't combine it with other XP practices.
IIRC, he was some years back the mastermind of a big OO project at Cash'n'Carry stores. Is that right? It was supposed to be a killer major competitive advantage kind of huge leading edge triumph. Somehow, I never heard a success story kind of post-mortem on that one. What happened?
Heres another book to teach programmers how to write programs... because we programmers dont know how to program.
I'd buy these XP books if they were cheaper than toilet paper, to wipe my ass, but they are too overpriced for me.
Damn, this guy Kent Beck surely (and Martin Fowler, and Jeffries, etc.) surely can write a ton of books on the same topic.
It is all really the same philosophy - XP and refactoring and TDD (Test Driven Development), and so on. There is a lot of overlap there, and all is (obviously arguably) just good advice for approach to software development.
How many times can they repeat the same thing?
It is all just refactoring of the same material, same philosophies.
What's the big deal?
At over $30 USD per book, plus all the invitations to give speaches, presenations, and so on, it's quite obvious to me why they are doing it.
Isn't that a bit lame, though, at least for them?
Doesn't it get boring?
Simpy
Writing a little UI for each module was easy, as we only passed a few parameters back and forth. It added perhaps 20% to our coding time at most, and easily saved back 100% over previous attempts. Being NASA, we had very absolute deadlines and had to keep a tight rein on disk space, but we did it anyway.
Also at Logisticon (now defunct) a little later, a bespoke supply chain app for JC Penny's with close to a million lines of Fortran.
Same techniques, except we had code reviews instead of pair programming, still test-first though. Result was maybe a dozen bugs per major release. The stuff worked; good techniques overcame a horrible development platform (GA-440/Fortran 66/iftran) for happy customers. Pretty extreme.
Thou hast damnable iteration, and art indeed able to corrupt a saint - Henry IV, Act I scene II
How are you supposed to design a reliable schema if you don't do a complete design before you start?
For a project I've recently been on, we did the whole half-assed XP thing: skipped on design but didn't really make up for it enough in other ways. It was a bit of a mess.
Anyway, I spent heaps of time correcting for database changes that came up late in development, and that was a pain. Because a schema change in one place means code changes all over the place... you get the idea.
So how do people usually get around that? Is there a good strategy to abstracting the database away like crazy that gets around the problem?
Believe with me, my saplings.
All extreme programming does is hide your mistakes cause you write the code to pass the test case, but nothing else.
I've been doing test and QA longer than any of you have been doing programming (or the guy who wrote the book) and before that I was programming and designing circuits.
Reading the comments it's clear that most of you don't really know how to write code, you just hack on it till you think you have something that works and leave the problems to be patched by others after the release.
Coding is easy, ANYBODY can do it. Designing and planning are hard. Not a single line of code should ever be written until the ENTIRE design has been laid out and planned. People who feel they have to code before the product has been defined and designed always code in hundreds of bugs and errors. Letting your coders do all your own testing of course never finds the mistakes either. After all, if you could see the mistake would you code it in the first place? Of course not.
All these 'programming fads' are just that, fads. They won't deliver the goods. The way to do software projects was laid out over a decade ago, if companies would just FOLLOW THEM, we wouldn't see so much buggy crap turned out by companies.
This thread is turning out better than some others about Extreme Programming, like here and here.
I worked on a project that used XP for most of 2001. It was a liberating experience. We had two domain experts who also acted as XP coaches, which helped a lot. Our biggest problem was convincing some team members to suspend their disbelief long enough to give the XP practices a chance. At the end, we found we were about 50% more productive than similar, non-XP projects, despite spending a lot of time cutting excess code out of the project. About 20% of the source code was devoted to unit tests and mock objects to support the tests.
When budget-cutting forced us to halt development abruptly, we had 12 known bugs. 11 of them were GUI problems, which we could not easily unit test. We had 70-80% unit test coverage, most of it written under the mantra "write the test, then the code." This turned out to be a key factor in our code quality.
Having all those unit tests in an automated test framework gave us tremendous confidence to keep moving forward. This leads to the other key factor TDD provides a project: freedom from fear. Why worry about failing the regression tests at the next code freeze when you can run them every hour?
Our XP project convinced me that one big reason for quality problems in C-language software is the lack of automated unit test tools. Sorry, that's just another good reason to move to OO, even for embedded systems.
TDD is still valuable without the other XP practices. Short development iterations also deserve wider use outside XP.
For all the naysayers... Look, nobody is saying you have to abandon experience, judgement or common sense to use XP. What you have to do is immerse yourself in the experience -- add the flow of programming the XP way to the other tools on your belt. XP is a little harder than riding a bicycle, definitely easier than Tuvan throatsinging, and as hard to describe on the printed page as both.
That said, Kent Beck's testing book is pretty thin. It adds very little to what you'd get from reading Extreme Programming Explained plus the JUnit tutorial. To understand why people "get religion" about TDD, understand why people are religious about the most effective ways to get software development done. Two views that come to the same place from vastly different starting points are Alistair Cockburn's excellent book, Agile Software Development , and the "lean software development" material at Mary Poppendieck's website.
Even if an XP project succeeds, its not because it is valid process, but because so much money has been thrown at it that it cannot fail... much like the Amazon model.
I have worked on an XP projects that worked well. Why did it work? because there were only 2 developers and both of us worked on our own stuff rather than Pair Programming. Basically, we did the XP because our boss wanted it (because its a buzz word he'd picked up), and we told him we are using it, did a few code reviews as we normally do, boss was happy, we were happy... if we were asked to pair program... no work would ever get done.
I have also worked on XP projects that were plain stupid. Refactoring is not a good excuse for writing bad code. I have seen bloated, ugly code with lousy design at places of "ideal XP" and they wait for a factoring to get everything fixed, but by then it has become so ugly and bad, that nothing got changed. Lot of bad developers hide behind this XP ideas, and lousy code had been written. Somehow the XP philosopy seems to attract the bad developers, because it allows them to speak of the "good" way to write software instead of writing good sotware.
I find most stable, well written code I encounter is usually pretty modular and thus, able to be tested easily.
I have some misgivings about XP, having had a very, very bad experience with it in the past. But I do think there is something there... however, perhaps a lot of what makes XP work is that simply by writing tests first, they cannot help but write implementations that lend themselves to testing as you have noted! The resulting code is thus more modular and less prone to error.
I still think that XP presents a lot of overhead that might not be nessicary given the right people - like instead of having a thousand unit tests that you have to maintain with the code (one of the nightmares encountered), you have well-written modular code with just a few tests.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
for me prettiness is only thing interesting on proggraming, i will change job if somebody insist on not worrying about it
what is reason, you do programming?
This argument (that tests may be flawed, and so don't help) isn't as much of a problem as you think.
/zero/ difference to your error rate (compared to any other method that appears to implement a specification). In order to remove bugs, you have to do /some/ testing, so I have to assume you're advocating test-last.
Suppose 10% of the code you write contains errors (at random), and you write tests covering 50% of the code. Then you find 90% of the errors in 50% of the code (assuming your error rate in test code is the same as the error rate in 'real' code). Your error rate for the overall program should now be around 5.5%.
In other words, it doesnt matter if your tests can also be flawed, you'll still improve your code by doing testing. On the other hand, planning will make absolutely
It then boils down to whether test-driven or test-last is the most economic policy, and how much testing to do.
Anyway - since this economic argument (not flawed tests) is the crux of the matter, you should take a read of Beck's thinking on the issue, in May 1999 issue of C++ Report, particularly the last paragraph.
Cheers,
Baz
Four chords were strapped around a block such that, viewed from the axis of rotation, one would see a cylinder with an inscribed square. Cool trick that.
Programming methodologies are the same thing. I haven't seen anything in XP that I haven't seen elsewhere, using different words (for example, Steve McConnel's excellent Code Complete). Again, all methodologies have trade-offs and different emphasis, and some are more suitable for some projects than others, and again if your developers have enough self discipline they know how to do a project properly and don't need a set of rules to follow.