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.
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.
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.
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
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.
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.
JUnit is amazing. It's incredibly easy after you've written your first unit test. Here is a prime example of its use: I had about 50 classes spread out over a couple packages one of which is "core" to all the others. I had unit tests for all the code. I wanted to totally redesign how I implemented one of the core classes which is inherited by a number of other classes. I think people that don't have unit tests would shy away from such a large change. I simply backed up the old source file, put in the new file, and ran my ant script which builds, deploys (on appserver) and runs junit. After about 20 minutes of cranking through the unit tests, it finished with no failures. At that point I was 100% confident that my change worked and I wouldn't be surprised by a suble bug later. That is what junit is good for - peace of mind and confidence. You'll allow yourself to make changes to code (for the better) that you may otherwise have though too complex to attempt.
As for your first unit test, it isn't that hard. Use a standard naming schema like "FooTest.java" or "FooJUnit.java" for your test cases - this way ant can filter on those name and run junit against them while keeping your unit tests out of your distribution jars. Extend TestCase and overload setUp() and tearDown() - often you won't need those. Name your methods testXYZ() and junit will run them. Inside your test methods call Assert.xxx() on the things you want to test. You can test for null, compare to known values, etc. You can test to make sure exceptions should be thrown or not. Sprinkle in a little log4j and you can get more detailed progress of the tests.
-tim
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.
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.
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.
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
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.
Well, "extreme programming" is part hype and part common sense. The hype part is to educate management into the methods lots of people have been using for decades. Codifying it and giving it a sexy name helps legitimize these practices. Code reviews **are** useful sometimes as is pair programming, rigorous unit testing, etc., but this stuff has been happening all along with or without management approval.
Now if you're sitting next to your buddy, watching and commenting as he or she steps through some code, and your manager asks you why you're not at your own desk doing real work, you can explain that you're "pair programming" or code reviewing or what have you. Whatever. It's just a name for something everyone already does from time to time.
If you think the hype's a "load of crap" then I would tend to agree, but if it's the practice you object to, then you're obviously a rank beginner.
it's = "it is"; its = possessive. E.g., it's flapping its wings.
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...)