Slashdot Mirror
Java Tools For Extreme Programming
In recent years there has been a increased emphasis on Agile Software Development. The most prominent of these methodologies is probably Extreme Programming.
What sets Extreme Programming apart from most other Agile Technologies, in my opinion at least, is that it has provided practical, easy-to-use tools to support its way of working. Most of these tools (Ant, JUnit etc) are Open Source and freely available. However popular these tools have been with the Open Source and Extreme Programming communities, it has arguably been difficult to introduce them to traditional IT development environments. This has been primarily due to the problems of justifying spending time on 'playing' with something and the difficulties of retro-fitting new tools to an existing development environment (think projects of 150+ people which have been releasing for 5-10 years for some idea of the potential problems).
It's worth noting that when embarking on a new, large-scale project it's very difficult to find a book discussing the issues of controlled builds, integration and deployment in practical terms. The most valuable aspect of Java Tools for eXteme Programming is that it's alone in its market niche.
The book is mainly useful as (a) an introduction to the various building and continuous testing tools out there and (b) a tutorial to getting them setup and working on your computer. As the authors note, there's a critical period where the user must get some result after playing with the tool for a short period of time or just give it up as 'too difficult.'
From a technical standpoint the book is very readable, but it doesn't tackle any one subject in great depth. It certainly provides enough information to get you up and running, and also, perhaps more valuably, illustrates how to integrate the tools together. It's an excellent primer for those who want to use the tools but are unsure of how exactly to start.
What's covered? Here are the chapter headings:
- Introduction and Key Concepts
- Introduction to Extreme Programming
- J2EE Deployment Concepts
- Example applications
- Mastering the Tools
- Continuous integration with Ant
- Building Java Applications with Ant
- Building J2EE applications with Ant
- Unit testing with JUnit
- Testing Container Services with Cactus
- Functional Testing with HttpUnit
- Measuring Application Performance with JMeter
- Load Testing with JUnitPerf
- API and Tag Reference
- Ant Tag Reference
- Ant API Reference
- JUnit API Reference
- Cactus API Reference
- HttpUnit API Reference
If you use some of these tools already will you learn anything? Probably -- I personally have been using JUnit to test EJBs for almost nine months now but didn't know about JUnitPerf or Cactus.
Should you buy it? If you're new to the tools, then Yes. If you work in a professional but traditional IT shop, I'd buy one for the group (I have). It'd be particularly useful when dealing with management and proposing changes to working processes, or when trying to bring co-workers up to speed and sell them the benefits of agile ways of working.
You can visit the book's website at Wiley. You can purchase the Jave Tools For Extreme Programming from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
"Build early and often" is one of the continuous integration mantras, and CruiseControl helps out with that. By having a coninuous build cycle, you can catch errors literally within minutes of when they're committed to the source repository. CruiseControl will email you if builds don't work, and also has a nifty servlet to let you track builds on the web. It's definitely worth a look.
This book is *terrible* for extreme programming - I don't know why they even put it in the title (um, ok - to sell more books...) It's a good book for the price though - don't just take my word for it:
amazon reviews
RC
Personally, I learn programming concepts well when I have a real book instead of web research. Either I missed this book or it's new, because learning JUnit, Cactus, and Ant all at once on a single project from only web research is rather challenging.
This is going on my shopping list.
Last year, I actually had the opportunity to ask Kent Beck if he had any suggestions for adopting XP to large projects (200+ people across multiple geographic locations), and unfortunately, he wasn't too optimistic. He indicated that the largest projects he's tried XP on were 20 people or so.
Other issues we've had when considering adopting XP in our organization are that XP tends to assume that you will be developing for a single customer with a set of evolving - but consistent - requirements. In our reality, we have multiple customers, who want different things.
Finally, XP doesn't seem to offer any solution for testing GUIs, which make up a large part of our product.
So while I'm very excited by the promises of XP (and will likely buy this book), I think it is important to temper your enthusiasm with a healthy dose of reality, and consider that XP relies on some subtle preconditions in order to deliver on the promise of a smooth and successful development cycle.
Like woodworking? Build your own picture frames.
Overall, they're cheaper than bn.com (I have no association with either, but I've found good deals on these book resellers).
Sig: What Happened To The Censorware Project (censorware.org)
What does Ant (an extremely useful buildtool for Java) have to do with Extreme programming? Nothing! I can't really imagine why anyone would need a book on Ant (can't say much for the others) -- there's pretty self explanatory documentation here. Since extreme programming strikes me as a load of crap to begin with, this is all probably a good thing.
YOur right about the amazon reviews. What is it with these "reviews" that get posted here -- the table of contents for christ sakes? It seems like book reviews are just an excuse to post a affiliate link to a book store. For shame slashdot. For shame...
I am not a number! I am a man! And don't you
I am a development manager with a large (20+) team; I am gradually introducing some aspects of extreme programming into the organisation, and so far, it's working pretty well.
The concept of user stories is great for getting our multiple customers to get to grips with their requirements; the tactile nature of the cards allows the planning sessions to be participatory and inclusive, the customers understand the trade-offs and the developers get to understand what they're _really_ being asked to deliver.
Pair programming and continuous testing have produced decent results; the main problems we have are accomodating sickness and holidays into the project plan.
On the other hand, our organisation does insist on some of the more traditional aspects of development management - a formal "Project Manager" role, regular progress reports to the executive team, functional and technical specifications etc.
I don't see how you could realistically hope to convert an entire team to XP overnight. The gradual introduction of some of the basic concepts - esp. those which can be explained as "quality oriented" - is a lot more likely to succeed.
I've read the book, and it's okay; the editing could have been a lot tighter (there's page after page of code printed out which outlines the application to be tested, not the tests themselves, there is a huge chunk devoted to the documentation for the tools which is available online etc.), and it kinda drifts away from the point now and then. If you want to get up to speed with Ant, jUnit etc. it's worthwhile, but don't expect to become an XP xpert.
It's all very well in practice, but it will never work in theory.
I have a question for the JUnit users out there. Basically we are doing unit tests here in the following way:
1. We mark the test code in the classes between special comment lines (so that it can be programmatically removed)
2. The tests are in static methods with the prefix "test", called by a Test.class in each package. Test.class has a main that just calls the other tests
3. Each test prints out on a single line the class it's in, the name of the test and "passed" or "failed" and the failure may have extra info as to why it failed
This is working well for us, but considering how many people are happy with JUnit I was wondering what it provides over this way of doing unit tests? Basically, I'm just looking for some of the things that JUnit has provided you (above and beyond what the above gives) and maybe a real use example, but don't really need to be sold on unit testing (we already think it's great and are doing it).
F
-no broken link
When I think of extreme programming, I think of writing code on a laptop while BASE jumping or while being attacked by a shark.
I'v enot read the book, but looking at the chapter headings they seem to have leftout one great tool for XP in Java - the various refactoring browsers that are now hitting stride for Java, including JRefactory, IDEA (my favorite IDE period), jFactor, and X-ref (for the Emacs lovers)
With the XP RefactorMercilessly principle, IDE support for for refactoring is a must on big projects. Custom writing a Perl, sed, or awk script to move a method from one class to another (in its argument list) is possible, having IDEA or another refactoring tool handle all the updates across 2000 changes in 700 files is a lot nicer.
-Frums
The most scary part of the whole eXtreme Programming stuff is the pair coding. For those who don't know, it's the idea that all programming should be done by two people at the same time one actually coding and supposed to think "strategically" (about integration, structure and stuff like that).
:( I hope people will soon realize that it's impossible to think when you have someone watching over your shoulder.
Now some poor programmers don't even have a PC for themselves. They have to share it with a colleague and they are even denied their most basic right to have a few square meters of personal space.
I would never accept such working conditions but it's unfortunate that this seems to happen more and more.
True warriors use the Klingon Google
Why should Software be any different ?
Because it is !
Lets see:
Houses, Bridges, planes = Tangible, concrete
Software = Intagible, computations
I'm just sick and tired of people thinking that only way to do Software is to try to fit it in models that are meant for something totally different.
Lets face it, Software Engineering is not (in most cases) like bridge engineering. Trying to build software like you build bridges just doesn't work.
Software is something totally unique.
please proff read !
One extreme programming tool written in Java which I haven't seen mentioned here is that of Naked Objects. I had play with it the other day and thought it quite a neat idea.
Java did live up to the hype, but no on the desktop 'though. Java is very much alive on the server side. Client side java pretty much never existed on the big scale ('though there are some very good client side java programms). Applets were killed by old and incompatible implementations of the JVM (not only Microsofts, but others as well). The Problem is/was that most Browsers shipped with a Version 1.1 JDK, which is just plain old and outdated. Microsoft never even shipped anything more up to date. You can use plugins to use more up-to-date versions of Java, but that's quite some trouble. And most Applets are just used as a flash-replacement and for this it really isn't worth to download the Plugin.
Totally Agree.
Software can be altered easially throughout it's lifetime. You can't take a piece of a bridge out make it better and put it back in.
Developing with XP let's you get to the point, realize your mistakes or places that can be improved, and do so quickly. The concept is that the design will evolve out of the code.
I have to admit, when I first heard of it I was the same way, but I've found that for small projects, with few people, it works well and the code does naturally evolve into a decent design using proper refactoring techniques.
Later-
XP is for hackers who want to improvise, and upon whom nobody relies for their survival. If people built houses, bridges and planes this way we'd all be up in arms about the lack of quality.
This isn't true - XP is no more for hackers than any other type of programmer. At the core of XP is building quality in from the first stages. For example, one of the XP techniques, pair programming, though very intensive, increases quality through a continual peer-review - you have two coders going at the same code on one machine - any line of code that doesn't cut the mustard is more likely to be found.
Additionally, XP tends away from 'big-bang' integration scenarios by having early releases, regardless of size - this means the system is all working together from the beginning, and that bugs residing in different definitions of what an interface 'really' means are found early before they cause problems. If that wasn't enough, there is also a large concentration on testing - before writing the code, XP users are thinking 'how are we going to test this? Exactly? What are the exact criteria for success of this unit?'.
It isn't a tenet of XP that you 'continually change each piece'.
XP isn't a tool for hackers, it's got nothing to do with it. Nobody is saying 'don't design the architecture of your system', nor is anyone saying 'change things around until they work'.
thenerd.
The camels are coming. I'm in love.
Been under a rock for a while, haven't you? ;)
:) have provided some seriously amazing libraries/frameworks/etc. that help programmers avoid reinventing the wheel -- or the bucket seat, the 5-speed automatic transmission, or even the 10-disc CD changer.
Okay, all ribbing aside, as someone who programs Java for money, let me give you the skinny: Java applets bite. More specifically, they are slow to download, prone to crashing, and subject to problems due to lack of control over the Java runtime available to the browser.
Java has, instead, found its niche on the server. Server-side programming is where Java works really, really well. Development is generally faster than with C/C++, and Sun and others (go Apache!
The other benefit that Java on the server provides is that web designers don't have to monkey with the code, and programmers don't have to deal (so much) with HTML.
Needless to say, everything above is a generalization, all generalizations are false (including this one), and YMMV.
The biggest reason for different source code for IE/Netscape is (IMHO) that IE's native Java support is frozen at V1.1.x. Most applets that I see on the web are coded for this level of Java and, generally speaking, run under Netscape....but since Netscape provides (I think) V1.3.x of Java you could definitely write a different version for V1.3 that has more features/whatever than the V1.1.x that you have to maintain for IE. Of course Sun released a Java plug in for IE to give it more up-to-date Java support....but you can't assume your customers all have it.
Having said all that, I think applets are the worst representative of Java usage. I write server-side Java and really like it. The server-side specs (JSP's, Servlets, J2EE) seem to be port across platforms quite well. When we deploy code on WebSphere (IBM's J2EE platform) it runs across Windows, Linux, AIX, Solaris,etc with no problems. I haven't tried porting EJB's between J2EE platforms but I have written Servlets & JSP's on one platform and moved them to another with no changes, although the deployment details (what goes where) may differ.
Java, Exteme Programming, Open Source. The title rings some warnings bells...
My experience with extreme programming is that it is simply a bass-ackwards way of development.
The advocates of eXtreme pr0gramming who love to "refactor" their code on a daily basis seem to have the same mindset as the people in my upper level CS courses that would spend the entire weekend in the computer lab on their projects, and complain about their grades and the time they spent afterward.
I'd spend a couple hours making object relationship diagrams, program flow diagrams, etc beforehand. I'd show up at the lab Saturday morning at 9 and leave at noon, and the looks these students gave me were a combination of hatred, jealousy, and disbelief.
IMO, it's just a process choice. Planned, focussed development, or tinker-till-it-works.
Extreme Programming has been discussed at /. before, and the links provided at the beginning of this review were useful, but the review itself falls short of mentioning how the authors integrate these tools with the extreme programming philosophy.
;P ).
Check me if I'm wrong, but from my initial readings, XP relies heavily on customer feedback, and short-term iterations serving to adjust the project plan "on-the-run" so to speak, which minimizes time loss incurred by the difficulty of making accurate long-term estimates in programming, and compensation made for fickle end users. While testing is a large part of XP, is only a part of XP. What does this book say about implementing XP on the whole? Anything? Is this just a book about tools you may use to test your software? Can I test my software if I don't use XP?
The most valuable aspect of Java Tools for eXt[r]eme Programming is that it's alone in its market niche.
Excuse me for being picky, but what is useful about that? Are you saying that this is good if you want generic text that has XP written on the cover, or what?
The links describing XP give it a nice once-over on how you can think about the process of getting release versions out the door [which users and managers like]. I haven't seen anything that deals with the aspects of applications design that span beyond iterative releases, namely, systems that are proven to assist in the overall application architecture, and systems that are proven effective for creating flexible and useable GUIs. If you have a crack team of programmers, XP will cushion the unavoidables [ software is hard to estimate, and users change their minds frequently ]. Of course, you still need competent minds at work on the overall architecture of your code, and that planning seems to be an afterthought in XP ( features first, architecture second, perhaps this is why managers like it
Also, for any large project, you are going to have developers who display special skill in certain areas, and some who display ineptitude in certain areas. Before you start saying, "well, just fire the inept", remember that firing and finding replacement talent isn't all its cracked up to be, and "failure to exhibit genius" isn't cause to send somebody packing (nor is it always wise). XP takes the stance that everybody should do everything, but oftentimes you'll find that some on your team just don't have it like the top dogs do. In many cases, you want an expert to code a critical segment and, while it'd be nice if they could teach the whole team their skills, in reality, that is not always possible. I believe in peer learning, but everybody do everything, well... excuse the pun but that sounds a little "extreme"
XP has good guidelines, but I have many questions about how to interpret those guidelines, and a text that puts XP on the cover should say something about them, IMHO. So you say this book is about tools for XP, not XP itself. Ok, then what tools does it discuss other than those used to test code? Are there any other tools? Are these tools only for use with XP?
I guess what I can take home with me is that if the buzzwords "Java" and "XP" are on your cover, than somebody will publish your book.
sunday, Sunday, SUNDAY...
At the Megaplex Arena,
Extreme, In Your Face, Programming Action!!!!
Java, Perl, C/C++, VB, and many, many more...
Geek-tastic and nerd-a-riffic!
Tickets going Fast!!!!!
Remember, this Sunday at the Megaplex, EXTEREME Programming!
We'll sell you the whole seat, but you'll only need the edge!
Yes. I have ex-coworkers who are in a very XP environment. Things they have learned include:
- XP is very tactical. You need someone at the strategic level guiding and leading.
- Productivity drops significantly after about 40 hours per week (they collect detailed statistics about defect rates showing this).
- Individual productivity appears to suffer, but the result of pair programming and short (two-week for them) iterations results in code that is easy to work on (read: good design) and very low on bugs (read: well written).
They've put a lot of support around their XP team to make XP effective, in the form of tools, processes, and people (roles). Without that, I suspect they would be disorganized and chaotic.
There's a time and a place for just about every methodology out there. XP is an effective approach to development as long as it's done in the right environment by people who understand (or can learn) how to make it work for them.
Lets face it, Software Engineering is not (in most cases) like bridge engineering. Trying to build software like you build bridges just doesn't work.
I think you're only right if you look at a special subset of software: those software projects where failure and loss are acceptable.
Read this article from the December '96 issue of Fast Company. It's about the the team that writes the software for the space shuttle's on-board computer systems.
Interesting stats: at the time the article was written, the previous 11 releases of the software had had a total of 17 bugs. Not each; total. In 400,000+ lines of code.
Great quote, from one of the team members: "If the software isn't perfect, some of the people we go to meetings with might die."
There's a big difference between computer programming and software engineering. Techniques like extreme programming may work well in a pure programming environment, in which the results of your work just don't matter all that much. So you software crashed; nobody got hurt, right? Just re-launch it, and remember to save often!
At the opposite end of the spectrum, though, software engineering is just like civil engineering, or mechanical engineering, or aerospace engineering. If you f*ck up, somebody may die.
Commercial software development is somewhere in between. If you don't have any discipline or oversight, your software will be so bad that your company will go out of business. On the other hand, if you institute military-grade processes, you'll never deliver a product in a reasonable time. So you have to compromise.
But people who say that software is totally different are just fooling themselves. In software, like everything else, there's good work and there's shoddy work. Putting a label on shoddy work and calling it a "technique" doesn't make it less shoddy; it's just gilding the lily.
Since this thread is turning into a discussion about Extreme Programming I thought I would throw in my experiences with it. I work on a web application which when I first joined the project was run very much "by the seat of its pants". The project was in its infancy and we were in constant contact with customers who had wildly verying ideas of what the finished product should be. At that time we were testing/building constantly with no documentation other than code comments. We were also taking requests right until the release. For these reasons I say we were doing Extreme Programming. Our customers loved us and we quickly made the project one of the top projects in a very large company. On a side note I have often wondered if Extreme Programming is a simply a justification for what programmers tend to do when left on their own. Well then our success bit us in the butt. The big wigs took notice and labled us "Mission Critical". Now we spend more time documenting the application then writting code. Any requirement a customer wants has to go through several levels of review, and they are never accepted just before a release. Management now "measures" quality by number of defects openned on a release. (Yes I too reject the whole notion of measuring a quality by the counting of ANYTHING). Releases now take longer, frustrate customers more, and have lowered the moral of the developers who now feel they are simply documentation monkeys. Yet Management insists the project is better than before. The moral of the story I have taken away from this experience is that even if extreme programming is the better method for a given project management will regect it. It results in more defects being found, more change which scares the hell out of management types, and finally code which isn't well documented so that management can't replace skilled help with code monkeys at a moments notice. You don't have to count beans to make coffee. However, management won't let you make coffee at all without knowing how many beans are in each cup.
I got news for you... in most cases, some failure and loss IS acceptable. Not all of us are writing software for the space shuttle. I'll bet you aren't, either. In most cases, what we're worrying about is getting something done, on time and under budget, that has at least moderate congruence to end user requirements. And in most cases, those requirements are a moving target.
The techniques of XP are incredibly useful in the world many of us have to work in. They work and produce tangible results.
As for the whole "software built like a bridge" crap... there's a bridge over the Mississippi near where i live. It causes traffic backups in both directions every day because it doesn't scale. They're planning on fixing it... it will take six years, cost millions of dollars, and make traffic even worse during that time. Does this sound like a software project to you?
Hand me that airplane glue and I'll tell you another story.
XP is about realising what you are doing, and how. There are too many projects that claim to use a one step design-build-test, overall, but end up having version 1,2,3,4 ...
...
XP realises that
a) there will be feature creep,
b) you must test, retest, and test again,
c) it's really how most developers work
If you had to change a bridge because the river got wider, would you insist on using the same parts as before - regardless of how long the bridge needs to be now?
"If the software isn't perfect, some of the people we go to meetings with might die."
boy, would I love to say that to some people at meetings I go to.
"Sure, We don't have to take the time to test it properly, but if we don't YOU might die.Whats that? I get the extra 2 days to test, why thanks."
There are 2 types of Software engineering:
One is good engineer and the other is bad engineering, often called 'programming'.
The Kruger Dunning explains most post on
This isn't a troll, or flamebait, its a standard old fashioned flame.
Peer Programming means continual review by two people, two bad people = bad code. 1 good + 1 bad = 1 slow average. Code review must be done by several people and must also include a senior resource to help less experienced ones.
This was also the tennant behind the Team oriented approach of the Mythical Man Month, which was based around the assumption of everyone should be good, just fire the rest.
XP is basically the re-hashing of some long held good ideas, interspersed with some total drivel from a bunch of hackers.
XP DOES say don't design the overall architecture of the system, it DOES say don't design how each service should work. It relies on the concept of Unit Tests where anyone will tell you that bad developers = bad unit tests.
XP is a sham and a fraud that is only allowed because the industry doesn't care about quality.
An Eye for an Eye will make the whole world blind - Gandhi
Hmm. I write and I write, but no one seems to read.
Not all of us are writing software for the space shuttle. I'll bet you aren't, either.
Nope. I'm writing software for customers to buy. Nobody will die if it fails, but my customers will get annoyed. Annoy 'em enough and they'll go elsewhere. My company will go out of business. My family-- and the families of all of my employees-- will suffer. While that's not the space shuttle, it's important to me.
See? It's that spectrum thing that I wrote about in my post that you evidently didn't read. At one end, we have hobbyists; it doesn't matter to anybody but them if their software fails. At the other end, we have stuff like the space shuttle and nuclear power plants: life and death stuff. My company considers our work to be closer to the space-shuttle end than the hobbyist end.
Jesus, don't you people work for a living? I can't believe you don't take your jobs more seriously!
As for the whole "software built like a bridge" crap...
If architects built buildings the way programmers write programs, the first woodpecker to come along would destroy civilization.
-- Dave Baranec
Intangeable? Bad software set a navy Battle ship adrift, how is that intangable? If software in medical devices fail and someone dies, are you going to tell there family it wasn't the softwares fault, its Intangable!
Whats that? a badly engineered software program lost all your customers account information? hey, its only computations, we can recompile it and fix it later!
The same METHODS apply to ALL forms of engineering. The fact that people have taken the we can recompile it and release a patch later mentality shows exactly how crappy the software development industry has become.
of course XP is a waste of time, because its not going to really catch on, It makes management accountable.
The Kruger Dunning explains most post on
This isn't a flame, it's a standard old fashioned rebuttal.
Your point about pair programming is completely groundless.
Scenario 1 - no pair programming
Two bad programmers, bad code
One good programmer, one bad programmer, some bad code, some good code.
Scenario 2 - pair programming
Two bad programmers, bad code but any mistake either of them see will be removed, improving the quality of the code.
One good programmer, one bad programmer, code up to the standard of the good programmer, and the bad programmer learns, hopefully becoming better.
XP does not say 'don't design the overall system' - you are misrepresenting it. A look at this talks about the plan for each release. Sure, bad developers = bad unit tests, but bad developers = bad product, nothing will guard you against that. Nobody said 'Extreme Programming will mean you have no bad developers.'
thenerd.
The camels are coming. I'm in love.
Maybe you should read the books. There is nothing in XP against good design. What it isn't based on, however, is overdesign - attempting to design a system that will meet the (predicted) future requirements of the customer.
This issue of "hard" enginerring is clearly addressed. The point is that things like bridges, buildings etc, are not easy to alter once you have built them. If you find that the bridge was originally specified to be a footbridge and then the customer decides that what they really wanted was a road bridge, then it is very difficult to retrofit this new requirement. It has always been believed that software is the same - that changing it half way through is a very costly thing to do.
However, XP claims that with a good unit test harness, it should be, and in my experience is, very easy to change the underlying implementation of the code without breaking anything. You can't just rip out the entire ground floor of a building, but you can reimplement your decisioning code without the entire application falling down on you. This means that it becomes much easier to fit later requirements as and when they are needed. The XP project that I worked on had a major change to both the business requirements and, as a result, the whole way of interacting with an external system.
We had designed the package up front, but had designed it to do the requirements as they stood when we started. There was no suggestion to us of this other requirement at the start of the project, so no amount of analysis or clever design would have allowed us to code for it. However, once the new design was produced from these requirements, it was a trivial (1-2 days) task to recode several of the back-end classes to have the new flexibility in communication that was required (but with the same functionality). The unit tests allowed us to be confident that we had not broken anything. It was then another quick job to add the new functionaly, and we had a new working system.
None of this meant skipping design, or hacking. It just meant doing the amount of design that was appropriate at the time, and building a framework to allow us to change (hence "agile methodology") when requirements change.
You can't take a piece of a bridge out make it better and put it back in.
Um, well, actually yes you can.
They took out each segment of the bridge and replaced it with a new one. The work was done at night, with traffic flowing during the day. Quite a piece of work....
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
Damn, there goes my hole analogy!!! :) At least I got a pun in there.
I don't think you have actually tried XP. I have and while I *do* think that XP has some flaws, it is not just hacking. XP is intended as a way of producing high quality (but not guaranteed correctness, space-shuttle grade) code that solves the business problem. I think it does a good job at that; almost certainly better than traditional waterfall processes, for most business problems.
Dave Thomas described two problems with XP that I agree whole-heartedly with:
* YAGNI principle doesn't hold. According to XP you must always use the simplest design. However, sometimes experienced developers know the right solution from the start and doesn't have to get there by evolving the design.
* XP puts too much responsibility back on the customer. In my experience this is very true; Too much choice is almost as bad as only being able to make decisions up front when you have little experience to base your decisions upon (analysis phase in waterfall process).
The pros on the other hand is:
* Higher quality
* Tunable quality (you can turn the knob up and down as you go, not very far down though, or the process will stop working)
* Fast pace
* Solves the business problem - doesn't just deliver on a requirement spec (which describe a system that may or may not actually solve the business problem)
* Happier and more productive developers
I like to think of XP and agile methodologies as applying a more scientific-research model to programming. ("Experimental Programming")
Engineering approaches focus on very well known, defined problems. The shuttle is a good example: the design of the craft itself has been known since the early 70s, the behavior of its systems are already well known through simulation and experiment years before anything is installed or implemented. (The unknowns, or 'poorly knowns' can result in disaster, ala 1986) Mechanical engineering of any type follows the same process. Behaviors, requirements, and designs are known far in advance of attempting to build or implement.
However, business software is really not like that. Requirements are never that well known, and subject to change, even while the 'engineering' is being done. In chemical manufacturing, the unknown and changing conditions are tested constantly and adjusted as the process continues. (i.e. change concentrations, temperatures, etc. until you get the desired result.)
Business software development, with changing requirements and scope, is more of an empirical process than bridge building (or 'engineering software' for things like space shuttles.) I don't imagine shuttle software ever needs to be refactored. Of course, most companies cannot afford to measure ship times in terms of 5 or 6 years, either.
That's what XP is about. Design, Measure, and Adjust. How you implement XP is largely up to you.
See: Ward's Wiki (The Portland Pattern Repository) I'd post a link, but I want to make you do a little work before hammering the server!
One good programmer, one bad programmer, code up to the standard of the good programmer, and the bad programmer learns, hopefully becoming better.
I haven't tried pair programming, but my experience with bad programmers is that their main malfunction is often that they don't realize they're bad. They think they're super smart, and will argue ferociously for their demented complicated schemes. If you pair a good and bad programmer, you're likely to end up with either no code, or if the good programmer is willing to compromise to get something done, a loopy design that's been polished to work adequately by the oversight of the good programmer.
I guess my point is who is the most pigheaded person may have a bigger influence on the results of pair programming than who is the better programmer. And that you often get more humble the more you learn in this business.
A co-worker and I stumbled onto a GREAT way to do pair-programming: VNC.
It's awesome, you sit facing each other on your own computers (thus having your personal space) and then you can work together in an instant just by logging on using VNC to see the other programmer's computer. VNC is fully interactive and you both have control of the keyboard/mouse at the same time. It's perfect for pair programming.
There are many times when all you're doing in programming is a bunch of busy work. Copying and pasting fields from a database into get/sets of a Java class or something ridiculous like that that doesn't really need two heads. These can be done solo, but then when you start to get heads down into the business logic, you can just say "Hey, let's work together on this bit," and your coworker just logs on and you start collaboratively working together again.
This way there's no fighting over the keyboard ("Oh, christ! When are you going to learn to touch-type, give me that!", "No! You drive me crazy with your backspacing... I'll drive."). Whoever has the right idea can type just by doing so and the other person can watch for errors, comment on style, etc.
Mark my words, it works really well, it should be part of the XP standard.
-Russ
Me
Ant isn't really 'reinventing' the wheel, but making the wheel easier to manage (one file) and extend (ant tasks). It's a neat tool to have in the arsenal; I personally have found it easier and more intuative than Make for more 'complicated' projects. (Now, if I could just create an Ant script to automate and test builds of Oracle Pro*C programs...)
The reviews for the book and comments on Amazon, TheServerSide.com, JavaRanch are very encouraging. Thank you all. And, thanks to SlashDot for reviewing the book on this forum...
I'd like to thank some other folks.
This book would not be possible without the great set of tools written for building and testing J2EE. I'd like to publicly thank James Duncan Davidson et al, Mike Clark, Vincent Massol et al, Kent Beck and Erich Gamma.
James Duncan Davidson et al created Ant. The de facto build tool for Java. This is the glue for building applications and making continuos integration doable with Java.
JUnit is the regression-testing framework written by Erich Gamma and Kent Beck. After looking at this code base you can see this framework screams with design patterns and solid OOP, and is central to Extreme Programming development with Java. It is as if these guys wrote *the definitive books* on Design Patterns and Extreme Programming--oh yeah they did!
Russell Gold wrote HttpUnit, which makes functional web applications easy and fun. (It can also be combined with Cactus.)
Mike Clark extended JUnit to provide JUnitPerf, which does load testing and performance testing. This code is an excellent example of how to extend JUnit. Mike Clark is also a really nice guy.
Vincent Massol et al for creating the Cactus (was J2EEUnit). I use this tool every day at work to unit test JSP Tags and EJBs. This is a truly novel tool. (BTW Nicholas Lesiecki, the co-author of the book, is an active committer on this project.)
Vincent Massol of Cactus contributed to the creation of the book. He reviewed the chapter on Cactus. His acknowledgement was accidentally omitted from the book during publication.
I am not implying that anyone mentioned above endorses the book or name dropping. I just wanted to thank them for contributing their time and effort to create these tools and then just give them away! Without them this book would not exist.
The book has been a bestseller under software development on Amazon most of this year. Thank you. We are blown away with the success of the book.
Check out these threads about the book if you get a chance....
Thread TheServerSide.com
Nick and I answered a lot of questions about the book at the JavaRanch as well...
Thread at JavaRanch
I've posted some more background information about the book here...
Book Web Site
I'll check back and try to answer any questions about the book. Thanks again.
The web site will soon have a sample chapter on it. Later, when we write the second edition, the book web site will have early drafts for review.
--Rick Hightower Co-Author of Java Tools for Extreme Programming
rick hightower dot com
Link to book web site
Java Tools for eXtreme Programming describes techniques for implementing the Extreme Programming practices of Automated Testing and Continuous Integration using Open Source tools, e.g., Ant, JUnit, HttpUnit, JMeter, and much more.
There are other great books that cover other aspects of Extreme Programming. This book focuses on Automated Testing and Continuous Integration.
The book does mention XP throughout, but does not cover all other practices of XP in detail. This book focuses on the mechanics of XP. Other books cover the philosophy of XP quite nicely and there was no need to repeat it in this book. There is an introduction to all aspects of XP, however, the focus is on Automated Testing and Continuous Integration.
The book contains small examples and tutorials on each tool. The examples cover building, deploying, and testing Java and J2EE applications.
In addition to small examples, there are larger case studies. The case studies are larger more realistic examples. We have case studies involving XSLT, EJB, Struts, JDBC, etc.
Each case study is complete with an ant build script and several tests, written with JUnit, HttpUnit, Cactus, JUnitPerf and/or JMeter. The case studies focus on building, deploying and testing J2EE applications with Ant and JUnit.
There is also a reference section for APIs. Instead of rehashing the API documentation, the reference section has example usage, i.e., code examples for the important classes and methods.
Although this book speaks from an XP perspective, you need not practice XP to benefit from it. For example, you do not have to adopt the entire XP methodology to get value out of this book. Automated testing, for example, can help you refactor code regardless of whether you are doing pair programming or not. Continuous integration can help you detect and fix problems early in the lifecycle of the system regardless of whether your customer is on site or not.
There are some really great books on XP. Three of my favorites are as follows:
Extreme Programming Explained: Embrace Change by Kent Beck
Planning Extreme Programming by Kent Beck, Martin Fowler (favorite)
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by Scott W. Ambler
You will enjoy this book as it covers topics not covered in other books, i.e., essential topics that are critical to J2EE and Java development. This book is highly rated and is doing very well. If you are thinking about buying a copy check out these reviews reviews
rick hightower dot com
Actually the speed improvement is due to javac not Ant, and the same result can be achieved in a makefile. The difference, here, is that Ant is intended for Java programs and has built in this optimization already.
For example,
all: Class1 Class2
javac -classpath . `cat ClassList.txt`
rm ClassList.txt
Class1: Class1.java
printf "Class1.java " >> ClassList.txt
Class2: Class2.java
printf "Class2.java " >> ClassList.txt
Healthcare article at Kuro5hin