Java Meets XP: Two Reviews 211
| (see each) | |
| author | (see each) |
| pages | (see each) |
| publisher | (see each) |
| rating | (see each) |
| reviewer | Peter Wayner |
| ISBN | (see each) |
| summary | Two books which explore the use of Ant in Java software development |
The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.
The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.
Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.
While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.
Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.
In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.
| Ant: The Definitive Guide | |
| author | Jesse Tilly & Eric M. Burke |
| pages | 260 |
| publisher | O'Reilly |
| rating | 7 |
| ISBN | 0-597-00184-3 |
| summary | A methodical, in-depth look at the Java tool. |
The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.
The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.
| Java Tools for eXtreme Programming | |
| author | Richard Hightower and Nicholas Lesiecki |
| pages | 513 |
| publisher | John Wiley and Sons |
| rating | 7 |
| ISBN | 0-471-20708-X |
| summary | How to use some Java tools to transform extreme programming theory into reality. |
I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.
If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.
Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.
Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.
X-treme Programming (Score:5, Funny)
so? (Score:2, Funny)
Too bad you can't run VB on solaris...
Re:so? (Score:1)
Re:so? (Score:1)
Re:so? (Score:1)
Before anyone flames me, I code a lot of Java and I currently develop in it for a living and have done it under both Linux and Windows so I can speak with some authority on the matter.
Re:so? (Score:2)
Re:so? (Score:1)
Java was meant for a 64-bit environment and runs about as fast as a dead snail on a 32-bit system.
VB is good to write code quickly (Score:1)
VB on Solaris (Score:2)
not running VB on solaris might as well be a security feature opf Solaris as it protects it from run away programs and HORRIBLY coded apps...
Actually, a VB compatible interpreter [gnome.org] runs on the Solaris operating environment. What protects the system from runaway VB apps is not a lack of VB but the presence of working permissions on the system.
The Joke (Score:1)
Well hypothetically (Score:1)
You can run java on any computer, as long as you have an java interpreter on that machine as well. So hypothetically, you've always been able to run java in XP, you just needed the interpreter.(or the processor understands javacode, which is highly unlikely, Probability --> 0)
Just a humourous thought.
Transmeta + Java = speed (Score:2)
(or the processor understands javacode, which is highly unlikely, Probability --> 0)
Talk to Transmeta. Transmeta's Crusoe processor [transmeta.com] runs programs through dynamic recompilation of bytecode. Current products emulate Intel x86 bytecode, but the Code Morphing recompiler is a piece of software and can be easily replaced with one that understands Java bytecode or .NET MSIL bytecode.
...from across the room our eyes met... (Score:3, Funny)
...if only I had foreseen Bill and Scott walking in on us that one day... lord knows why they were hanging out together, but suspicion can make people do crazy things...
Why two reviews? (Score:3, Insightful)
IMHO, Anyone who needs book to figure out Ant should be shot.
Brilliant... (Score:1)
Re:Brilliant... (Score:1, Informative)
Re:Brilliant... (Score:2)
Now, of course, Microsoft is using the word Agile regularly in adveritisng.
Ugh. Maybe the XP community should embrace a new name for it. Call it "Fred". Of course, MS could come out with a replacement for MS Bob with that name
Cruise Control (Score:5, Informative)
Re:Cruise Control (Score:5, Informative)
Even more important is Anthill's support for multiple projects, complete with dependency graphs. Support for multiple projects is such a must-have feature (for me, anyway) that choosing Anthill over CC was a no-brainer. It's even open-source, so you can tweak it to your heart's content.
Re:Cruise Control (Score:2, Informative)
Channing
Ant: Not Just for eXtreme Programmers (Score:4, Insightful)
It's important not to lose sight of this in all the troll^H^H^H^H^H enlightened debate about XP that will surely accompany this review. We used Ant for a number of large Java development projects and we were not an XP shop by any stretch. As the reviewer says, Ant really shines when you start making use of various extensions. In our case, we were able to wrap most of the software release process (synching from Perforce, rebuilding and packaging the code, and uploading the distribution to an ftp site) within a collection of Ant tasks.
Book reviews with Affiliate links (Score:4, Informative)
Maybe the slashdot editors could pick up the clue stick on this one?
Re:Book reviews with Affiliate links (Score:3, Insightful)
I did think of that... (Score:3, Interesting)
Granted this is all largely theoretical as the vast majority (all?) of the reviews on slashdot are crap. They frequently are less informed than the average reader reviews on Amazon...
/. review (Score:3, Informative)
Some more information about Java Tools For Extreme Programming can be found on this earlier review [slashdot.org] of
Do the tech buzzwords annoy anyone else? (Score:3, Insightful)
Some of us are hard working, college educated computing professionals, not dim-witted adolescents with the urge to jump off of a cliff without a parachute. We need to take our field or work back from every idiot that can put the three brain cells together required to write a stupid book, or to introduce a brand new moronic buzzword.
(Ok, I'll get off my soapbox, you can now mod me to -1000 loser-troll-flame-bait)
Re:Do the tech buzzwords annoy anyone else? (Score:5, Funny)
I predict that Q will soon rise and topple X as king of the buzzletters.
Re:Do the tech buzzwords annoy anyone else? (Score:1)
The thing I find most distressing is that many people don't try to learn how to use the tools they have to solve a problem, and instead wait for a new tool to emerge and solve the problem for them. We all know that tools don't solve problems, people (with or without tools) solve problems.
Anyways....I'm buzzing...
Re:Do the tech buzzwords annoy anyone else? (Score:1)
Re:Do the tech buzzwords annoy anyone else? (Score:2)
No, I disagree: "M" for mobile will be hot.
Example: mMode [attws.com]
Err. I can't think of more. Someone help me out.
-Russ
Re:Do the tech buzzwords annoy anyone else? (Score:2)
"t", you see, is for Trust(ed). email is old news, t-mail is where it's at. t-business. t-brokerage. t-communications. It rolls off the tounge so nicely.
But then the marketing department got distracted by something shiny and we never heard about the big "t" again.
Re:Do the tech buzzwords annoy anyone else? (Score:2)
Huh. That sort of makes sense. So maybe the next letter will be one of the ones that rhyme with "e"
b, c, d, g, p, t, v, z
z is past. So is v (virtual). None of the rest are particularly sexy, though maybe I'm missing something...
-Russ
Re:Do the tech buzzwords annoy anyone else? (Score:2)
Perhaps you have never heard of the G-spot. That's pretty sexy (sorry I couldn't help it).
Re:Do the tech buzzwords annoy anyone else? (Score:2)
When z is pronounced correctly, it sounds like "zee" when uptight, pissant, backwards old-world countries pronounce it, it sounds like "zed".
Note that there's 280 million Americans and only about 120 million Brits, Canadians, Australians and Kiwis combined, therefore the numbers vote for "zee".
The Indians, however might swing the vote, but I'm not sure how they pronounce it.
-Russ
Re:Do the tech buzzwords annoy anyone else? (Score:2)
Re:Do the tech buzzwords annoy anyone else? (Score:2, Funny)
>I blame the rise of X near the end of
>the internet bubble
Yes I expect it was the sharp corners on the 'X' that burst the bubble. If only it had been an 'O' or a carefully oriented 'Q' instead none of this dot.bomb stuff would have happened and we'd all be snorting coke in the back of a limo as people flocked to our eCommerce B2B enabled portal eXperiences. Oops... there's that letter again.
grib.
Re:Do the tech buzzwords annoy anyone else? (Score:5, Informative)
BUT, that being said the XP name came from the fact that everything is done to the extreme. If testing is good then test everything. If integration helps find problems then integrate continuously. etc, etc.
I say to any developer - take a look at XP. It's simply a set of industry proven techniques done to the extreme. It does work and even if you don't use everything you can still bring good practices to your coding from it. You don't have to accept any cult, take the red pill, or claim allegiance to xenu to take advantage of good techniques. If you don't like them or find they don't work then say so, but don't judge a book by it's cover (for lack of a more fitting cliche).
Re:Do the tech buzzwords annoy anyone else? (Score:5, Funny)
// import java.util.*;
// TODO (6/5/02): Is it really a good idea to import the whole
// package? Needs research
// TODO (6/8/02): Maybe consider using a different language altogether.
// public class XXX {
// TODO (6/12/02): What is best main class name?
// TODO (6/13/02): consider putting opening braces on their own line
// public static void main(XXX) {
// TODO (6/25/02): are the standard parameter names ok?
// TODO (6/30/02): need to design implementation here
// }
// }
// TODO (7/11/02): Not sure I understand the project requirements at all.
// Need to have an all-hands meeting to discuss the preferred
// word processor template because I'm thinking of writing a
// white paper before I do any more coding here.
// TODO (7/27/02): This program is stressing me out too much. I'm going to
// leave early today to see my gastroenterologist about my nervous
// stomach. Maybe I'll resign one day soon, but I'm not sure if
// that's the best decision.
What annoys me: Ant is broken (Score:5, Insightful)
I've used Ant, and concluded that it's only strength is that it comes with a bunch of modules ready-to-use. (Never mind that most of those modules would be five lines in a more modular, flexible system like make.) Further, in several respects, it has several serious regressions compared to other build systems. In light of this, it seems to me that the main reason Ant is popular is that it attempts to cover for the deficiencies of common Java compilers. What a mess!
The first regression is that Ant (by default) doesn't do reliable rebuilds. The most basic function of a build system is to produce correct output, and Ant doesn't do it! Its default algorithm for rebuilding is to compile only those source files that are newer than their corresponding class files. So, for example, if you change an interface, Ant won't recompile all the classes that implement the interface. You won't know that they are broken until you (or someone else) tries a full rebuild.
Ant has a "depend" task that attempts to fix this, by tracking source dependencies. Unfortunately, because most Java compilers don't do their part, Ant has to do this in an utterly kludgy way--by parsing class files! Not only is this slow and has some weird side-effects, it's still not completely reliable: Only the compiler really knows what files depend on what others. (For example, if it in-lines a constant, this may not be evident in the class file.) However, as far as I know, gcc is the only Java compiler that can output correct dependencies (jikes claims to do it, but is broken). Even if your compiler does output dependencies, you can't easily use them with Ant, because it stores its dependencies in a non-standard format.
Another regression is that in Ant, individual source and class files are not first-class objects to the build system. You can't easily depend on, or ask to rebuild, a single class file. It's all or nothing. This too is largely due to compiler deficiencies: There is no way to tell most compilers to compile only the given sources; they insist upon compiling everything they think is out-of-date (again, gcc is an exception). This misfeature takes control out of the build system's hands, with the result that "recompile everything that's out-of-date" is the only feasible approach. Another effect is that parallel and distributed builds cannot be done reliably.
Not to mention,
I don't even know where to start on that one. All Ant shows is that if you give people a half-working workaround for broken tools, they'll flock to it.Re:What annoys me: Ant is broken (Score:2)
Re:What annoys me: Ant is broken (Score:2)
What can I say, except that I suspect you're exactly right. Particularly, I had forgotten about the cross-platform part of Ant's appeal (I won't touch a Windows without Cygwin, but it's no doubt a hurdle for Windows natives), which I suspect is the biggest factor.
Re:What annoys me: Ant is broken (Score:2, Interesting)
The issue with compiling more files than you ask for? That's javac or jikes for you; they pull in things they need, whether you ask for them or not.
Finally, you need to play with cruise control or ant hill. Have something on the net do clean builds and tests for you instead of you doing it yourself.
-steve
Yes I do work on ant
Re:What annoys me: Ant is broken (Score:2)
Well, with Cygwin you can. :-)
(I forgot about the cross-platform part, because I subconsciously block out Windows.)
Judging book by its cover (Score:3, Insightful)
Look man, you might be educated to be a programmer, but if you are worth anything to your employers then you implement some sort of software design methodology, and that's all XP is: it's a lightweight, high-discipline approach to delivering software to a client.
You can argue whether or not XP works, but if you are ridiculing and avoiding it just because it has the word "extreme" in its title then you are a poor programmer and a fool. Since your entire post consists of mockery you leave no choice but to believe you are both.
Java already met XP (Score:3, Informative)
Java and XP are a natural combination anyway, since a lot of the emphasis of XP is to fixing crappy code. Since lots of Java code is written by your standard junior-to-mid-level Java programmer (usually an ex-VB or ex-ASP flunkie), it usually needs a lot of re-writing (oops, "refactoring"!).
That being said, I don't see how a build tool is related to a programming methodology. Is it because it has a fairly standard JUnit task? You could easily get make to do that.
Besides, reading a book now about Ant is foolish, because (hope, hope) Ant 2 will be available soon, which hopefully fixes Ant's more egregious kludges and bugs.
Re:Java already met XP (Score:2)
Surely the emphasis of most XP practices is to avoid ever writing that crappy code? That's what the evolutionary sort of development model it advocates is all about.
In fact, I can see some would even argue that XP hinders fixing crappy code (reasoning on request, but I'm not going to feed the trolls uninvited :-)). Then again, since you're not supposed to get that far in the first place, whether that's a liability or not is a moot point.
Unit tests pass != good code (Score:2)
I think this is actually where I disagree. Good code must be (a) correct and (b) maintainable. Good unit tests guarantee the former if, but say nothing about the latter. It is therefore quite possible to write crappy code that passes all of the unit tests.
And herein, IMHO, lies the single biggest weakness in XP. In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design, and left it essentially to chance. If your development team consists purely of top-10% programmers who work well together, then certainly they will "refactor mercilessly" and maintain/develop a tidy design. However, most project teams don't, and in my experience will be "at the mercy of refactoring" instead.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
Re:Unit tests pass != good code (Score:2)
In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design...
Continuous refactoring is a type of maintenance. How can you claim that an emphasis on refactoring could reduce maintainability? Doing refactoring will cause programmers to try to write refactorable code, because it's in their best interests. Refactorable code is EXACTLY maintainable code.
Unit tests are not a part of maintainence, but they are a helpful part of maintainability. With unit tests you not only have a safety net to catch you when you make an out-of-spec change to a unit; you also have a readable spec to show you what normal, expected use for the component is. If you want to reuse a component, you first look at its unit tests to see that its author expected your type of use, and if not you add unit tests which DO typify your expected use.
An emphasis on refactoring, dual authorship, and reuse is DIRECT encouragement to write maintainable code, as well as constantly increase maintainability.
In fact, XP is often typified as continuous maintenance; most critics and proponents agree that XP projects are in maintenance mode almost from day one. Your accusations otherwise are so out of the blue it's hard to fathom where they came from.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
That's not the right question; the answer would be useless. The right question is, do you really have a simple change? Consider that the codebase in an ordinary XP project has gone through MANY simple changes, and hasn't ever been failing its tests for that long before. Your change shouldn't be anything special.
The XP thing to do is to back out of the "simple" change and redesign it in parts which will result in new functionality being added every week, and the code passing all its unit tests every day.
If you don't do this the XP way, then how WILL you do it? No other way is as amenable to requirements being added after the fact.
It's also possible, of course, that the codebase is totally inappropriate for your new requirement. Not every requirement can be added to every software product.
Re:Unit tests pass != good code (Score:2)
It's very simple. Most refactoring is small-scale, of the type typified in Fowler's book. As you make more and more small-scale changes, you can all-too-easily drift away from any coherent overall design. We've all seen projects where hacks on top of hacks have rendered a codebase beyond usable.
There is simply nothing in XP's approach to force developers to maintain such a consistent design. It relies solely on their skill and experience to see how something should be changed both to add/fix the feature at hand, and to fit in with a clean and integrated whole. In the traditional world, you have a general idea of that clean and integrated whole at the start, and you maintain basic documentation on it as it evolves so you can always go back and see where the problems lie, which parts aren't flexible enough, and so forth. XP just doesn't have that.
Sure, just like all programmers think through the problem before they start writing, and spend the time testing thoroughly afterwards, because the time more than pays for itself in the long run. No wait, sorry, most of them don't. What makes you think they'll be any less lazy under an XP approach?
Yes. But code that's been involved in five independent refactoring exercises in the last month may or may not still be easily refactorable in time for the sixth. The traditional development approaches have an answer to that: the design phase. XP explicitly does away with a design-first approach, in favour of placing the passing of unit tests above all else. And, as I noted when I first entered this thread, such an approach guarantees only correctness, not necessarily maintainability.
Re:Unit tests pass != good code (Score:2)
Yet all your arguments show that it'll produce maintainability, not correctness. Think about it -- correctness isn't shown or implied by the existance of tests.
But code that's been involved in five independent refactoring exercises in the last month may or may not still be easily refactorable in time for the sixth.
On the contrary -- code that's been though five independent refactorings will almost certainly be ready for a sixth, because the team has been reworking it so much and has already proven that it can be independently refactored.
Actually, in real use, by the time you've done 5 independent refactorings you've got a library-quality chunk of code, because you've proven that the same basic idea is useful in in as many as six independent contexts.
Doing refactoring will cause programmers to try to write refactorable code, because it's in their best interests.
Sure, just like all programmers think through the problem before they start writing, and spend the time testing thoroughly afterwards, because the time more than pays for itself in the long run. No wait, sorry, most of them don't. What makes you think they'll be any less lazy under an XP approach?
Let me add a word: because it's in their immediate best interests. If they know they're in maintenance mode, and they're doing their work in a maintenance style, they'll do work to make maintenance simpler. It's simple, short-term self-interest.
And that's the genius of XP: it takes the useful practices of design, testing, requirement analysis, reuse, and many other things, and changes them from long-term useful to immediately useful by moving them around.
Requirement analysis, for example, is moved from a big lump at the beginning of the project to small sums all throughout the project, assisted with the delivery of "evolutionary prototypes" (to use a non-eXtreme term). This way the people who know the requirements best (the customer who's paying for them) can see the fruits of their specifications so far.
Testing is moved from a big lump at the end to a colloidal dispersion throughout. In the process it changes character: from a roadblock between you and the customer, to a roadmap showing your intended route to get to where the customer claims to want you to be.
Design is moved from a huge up-front activity with no natural feedback, and is transmuted into a constantly ongoing process with many forms of immediate feedback, ranging from ease of testing (a testable design is not always a good one, but an untestable design is always bad, and because writing unit tests is how you express detailed design in XP, your design is certain to be testable right out of the gate) to fulfillment of acceptance tests to frequency and massiveness of refactorings.
All the known good practices are in XP, and they're all provided with a natural, immediate feedback; the is completely unlike the traditional approach you describe, in that the traditional approach fits the good practices in only with words on paper. The only thing keeping the programmers doing the good practices is their own determination; the only way you can tell whether they're doing them well is by looking at the schedule overruns after the fact.
-Billy
Re:Unit tests pass != good code (Score:2)
Eh?
Refactoring [refactoring.com] is, according to the subtitle of Martin Fowler's book, "improving the design of existing code." If you are refactoring all the time and still ending up with a sucky design, then you aren't refactoring very well.
You can look at XP as a series of tiny steps repeated over and over:
- write a little test
- think a little about the design of the code that the test implies
- write code until the test passes
- look again at the design and notice what is wrong with it
- refactor until your design is good
As many programmers have discovered, you can skip testing and design, and just go for the code. Well, at least a little while. Until your code reaches critical mass [tuxedo.org],at which point you are screwed.Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
Of course not.
I've never heard of a case nearly this bad with an XP team, although XP newbies will often blow an iteration (i.e., 1-2 weeks) on a big refactoring. This is always a sign that they haven't been doing enough refactoring as they go.
I generally diagnose this as "exessively high tolerance for ugliness and pain". On non-agile projects, one locks down a design and then just codes within that framework for months or years. The first design is never perfect, so one gets used to just hacking around a bad design, bending it to your needs.
In making the transition to XP, developers need to unlearn that behavior. About 80% of this can be solved by never, ever copying and pasting more than a couple of words. The urge to copy and paste code is almost always a sign that your design is bad. And by copying and pasting, one multiplies the ugliness. Instead you must figure out the commonality between the segments of code and abstract something beautiful.
Re:Unit tests pass != good code (Score:2)
Obviously. Then again, the vast majority of programmers don't actually program very well in the first place, IME. As with anything requiring skill, there seems to be some sort of bell curve of human ability. Programmers in, say, the top 50% of that curve write decent code from scratch. IMHO, only the top 10-20% could actually perform more than a trivial refactoring with the level of competence required to sustain a maintainable design long-term under XP conditions.
Sorry, I'd assumed the "six months" would be an obvious exaggeration. My example was simply to point out that, as with more traditional approaches, at some stage XP does simply rely on the human beings to get it right, and there are clearly situations under which they don't, and an XP approach doesn't help.
There is absolutely nothing unique to XP about this, however. I don't cut and paste more than the name of a function/variable to avoid typos, and neither does anyone else in the office. XP hardly has a monopoly on being able to program like a human being.
Re:Unit tests pass != good code (Score:2)
To start, maybe. After practice, probably not. And after regular practice with somebody who's good at it, the percentage should be much higher. And I don't know of any methodology besides XP (excepting, perhaps, some of it's cousins) that provide the formal support for assistance and cross-training that XP does through common code ownership and madatory pair programming.
But even suppose you're right, that this is a rare skill, and one that most programmers will never be able to learn. On a team of 5-10 people, you are likely to have one of those people who can handle such a refactoring. That person will end up doing all the hard ones under XP.
My example was simply to point out that, as with more traditional approaches, at some stage XP does simply rely on the human beings to get it right, and there are clearly situations under which they don't, and an XP approach doesn't help.
I still don't quite get your point here. Is it that no method will work with sufficiently bad programmers? True, but not very interesting. Is it that some other methodology or technique is better than XP for dealing with human fallibility? If so, please let us know what it is.
Personally, I think that XP relies much less on individual perfection than other methods do. Between common code ownership, pair programming, and relentless automated testing, there's just much less chance for an idiot to screw things up. But unlike more rigid methods, XP doesn't much get in the way of high achievers.
XP hardly has a monopoly on being able to program like a human being.
Very true, but few other methods support so energetically the development of those skills that so, so many of the programmers out there seem to lack.
Re:Unit tests pass != good code (Score:2)
Yes. In a traditional, design-first environment, you only need one good guy to be responsible for the overall design, and everyone else to follow it and be smart enough to ask questions if something doesn't fit the existing set-up. In an XP-based process, you appear to need one skilled person in every programming pair, a much more demanding requirement. The responsibility has been decentralised, so everyone now shares it and needs to be able to handle that.
I certainly wouldn't argue with that; I'm all for getting a more experienced programmer "mentoring" less experienced ones in real situations, and that is the reasoning behind much of the pair programming I have done in the past. But even with the greater rate of knowledge spread, you'll be hard-pushed to get from one or two good design guys being needed on your team to one in every two guys on the team being good at design. Granted, I've only ever been involved in a couple of projects that have tried XP seriously and long-term, but both suffered obviously from this particular weakness, hence my reservations that started this subthread.
Re:Unit tests pass != good code (Score:2)
This is theroretically true, but it requires iron-fisted control over design changes, and it also requires developers to have enough appreciation for design to know when they are doing it wrong.
Most of the time when I see a formalized architect/coder distinction on a project, it ends up being a) seagull-style, where a theoretician flys in, poops a lot of design on everything, and flys away, leaving the developers to deal with the mess, or b) rebellion in the trenches, where developers know that they can get away with ignoring the architects, so they just do their own thing.
I have seen it work occasionally, but it ends up being in spite of the formal division, rather than because of it.
In an XP-based process, you appear to need one skilled person in every programming pair, a much more demanding requirement. The responsibility has been decentralised, so everyone now shares it and needs to be able to handle that.
I could see how you'd get that idea, but that's now how it should work. As with the other model, the developers need to know when they are in over their heads and then ask for help.
With XP, though, there are a few things to support this. One is that only one of the programmers has to recoginize the trouble and ask the best designer for help. This could either come through a short discussion or through the master just getting swapped into the pair.
Another valuable piece of support is that XP requires frequent pair changes, so a design issue of any substance will get looked at by a variety of people in pretty short order. This doesn't just give you the benefit of many eyes; it also means that design problems are likely to get caught sooner.
Better, XP encourages experimentation and change. With the classic waterfall approach, you are stuck with bad design decisions for a long time. The ability to safely change my design as I go has substantially improved the designs I end up with.
But I think the most important one is common code ownership. Part of a team effort is that each person should make use of their strengths. If you're by far the best designer, then you should be looking out for design problems and fixing them, especially given XP's empahsis on aggressive refactoring. Common code ownership means that you are empowered to change anything that you think is ugly.
I've only ever been involved in a couple of projects that have tried XP seriously and long-term, but both suffered obviously from this particular weakness, hence my reservations that started this subthread.
I'd be intrigued to hear more! In particular, I'd love to know
Personally, I used to aspire to be an architect, and I still will occasionally take jobs like that. But I eventually realized that the only way I learned to design well was by writing a lotta code, which made me intimately famliar with the tradeoffs that a good designer had to make. But as soon as I was an ivory-tower architect, mere coding was considered beneath me, which cut me off from the source of my strength. Once that happens, it's easy to spend a lot of time on philosophical bullshit, debating the OO equivalent of angels dancing on pins.
Now, every day I analyze, design, write code, and design some more. I find it much more satisfying.
Xtream J4va UNVEILED (Score:2, Funny)
Clazz JazzyJava {
pubic voyd maine(Strig wordup) {
while(jav4_is_still_Xtream)
System.printl("you betta believe it sukka")
}
}
Java met Extreme Programming a long time ago (Score:4, Informative)
Refactoring (Score:5, Insightful)
Extreme Programming consists of a lot of distinct ideas including: small teams, two people per keyboard, unit testing, and refactoring.
The most useful of these ideas to me is refactoring. (probably followed closely by unit testing) Refactoring starts with the humble admission that at the start of most software projects, you really don't know exactly what the final product will look like. This implies that the design of the project will change during development. Refactoring is a set of techniques that allows the design of a program to change without making a mess of the code.
If you are interested in Java and Refactoring, you really owe it to yourself to check out Refactoring [amazon.com] by Martin Fowler. He has come up with a very well written book in the format of Design Patterns [amazon.com] that does a good job of enumerating and explaining many refactoring techniques.
Re:Refactoring (Score:1)
Re:Refactoring (Score:3, Insightful)
I disagree. None of those things was even slightly new in XP, and while we used all of them several times a day at my last job, we were hardly an XP shop.
What is new is the way in which XP advocates using them. Everyone smart writes detailed unit tests, but not everyone writes them first.
He didn't say they were new (Score:2)
He didn't say they were new. He just said that XP "consists of a lot of distinct ideas." Where do you read the word "new" in that sentence?
I know he didn't (Score:2)
Nor did I say he did. However, as you point out yourself, he said that XP consisted of various ideas. My point was that since it didn't invent any of them, and all of them are widely used elsewhere as well, there must be more to XP than that.
Re:I know he didn't (Score:2)
So were we, at my last place of work. We routinely ran unit tests against everything. We frequently worked in pairs for extended periods while coding/debugging. In fact, we followed pretty much all of the principles stated.
But we weren't an XP shop. We did design first (in fact, we had around 250,000 lines of framework code written up-front before the application proper was written, and it paid off big-time in later development). We didn't force one programmer to sit around idly without a PC to play with while his "partner" was writing Mickey Mouse code to an agreed specification using automatic code-generation tools. We were about as un-XP as you could get in our lifecycle.
So clearly there's still more to it than just those principles.
Re:I know he didn't (Score:2)
Used to work at a place where clearly the manager had read one software project management guide too many. He structured the whole team around a pair of programmers doing the main development, with supporting staff maintaining the documentation, writing little libraries and test tools, dealing with the clients to capture requirements, etc. All of this actually worked pretty well most of the time.
But he really did only give the principal pair a single PC between them. Since one of the first things the team did was get the library/tools guy to write automated code generators for the principals to use -- Good Plan(TM) -- instead of having to constantly rewrite the same boilerplate, it rapidly got to the point where either of the principal coders could spend 15 minutes generating the boilerplate for the next hour's development single-handed. I believe the adopted policy was that the other one would spend the 15 minutes making the coffee for the rest of the team...
Re:Refactoring (Score:2)
The same way you "know" that your unit tests cover everything perfectly: you rely on the competence of your engineers.
You can, and should, follow processes that make it easy for your engineers to do a good job, but software engineering is called that for a reason. At the end of the day, however good your processes, it is still a skilled job, and requires skilled workers to do it.
Re:Refactoring (Score:3, Insightful)
The same way you "know" that your unit tests cover everything perfectly: you rely on the competence of your engineers.
Ah, an optimist. But one who clearly hasn't tried automated testing.
I know a lot of good programmers. My dad is a good programmer. I have been programming since I was a kid, for more than 20 years now, so I flatter myself that I am a good programmer, too. But I have never met anybody who writes real unit tests and never sets them off accidentally.
But let's grant the theoretical possibility that you are an ultragenius programmer with the memory of an elephant, the focus of a cat on the hunt, and the endurance of a robot. All relevant chunks of code are in your mind at all points. You never make mistakes, you never forget anything, and you therefore never break unit tests. You can do the most complicated refactorings without dropping a stitch, even though your project consists of thousands of classes and millions of lines of code.
But what happens when one of your (human) coworkers works on your code? What happens when you and a colleague make simultaneous and conflicting changes? What happens when a new version of a library breaks a previous feature? Will you know without automated tests? No.
I used to think that unit tests were a nice idea, but far too time consuming and painful. I was wrong. For anything except the simplest throw-away programs, XP-style test-first programming lets me produce better stuff in less time and have more fun at it.
Re:Refactoring (Score:2)
On the contrary. I have been there, done that, and formed my opinions on the results.
One of the projects I've worked on has a lot of pretty advanced maths in it. We had special consultant-types in to write the code for it, because they were the only ones around who actually had the knowledge and experience to do so. They carefully designed unit tests to go through every algorithm they had, to ensure that it didn't go wrong, and they ran them religiously. Changing that code meant a mandatory rerun of all tests.
I raised six serious fault reports on that library within a year. Their "comprehensive" unit tests simply weren't.
I've also done a fair bit of work in the instrument control field. How exactly would you propose to write and run automated unit tests, when testing your particular piece of code requires driving 2 hours up the road to the site where the 8 tonnes of machinery you're driving is located? You can -- and we did -- do a certain amount by writing a software emulator for the HW you're driving, but as anyone who's worked in the field will tell you, testing with blanks is no guarantee it will work with live ammunition.
I wouldn't go that far, but in the past 2-3 years, I can think of three significant subsystems in the codebase I inherited that were so badly out of control that I rewrote them more-or-less from scratch and integrated them back into the system. And you know what? The level of testing I did at that point was way more than any set of unit tests I've ever seen. I got a second opinion on the design of each significant piece of code. I ran Lint and such on every file, until they were flawless. I did a code walkthrough through every significant path in the code before approving some of those changes. Then I exercised every option and every little setting, which is the most any automated test would do, if you could even write such a test in the first place.
Some of that code is now used by thousands of clients, hundreds of times a day, and in more than two years since some of those modules went live, we haven't had a single fault report on them.
You couldn't write automated tests to test the code I was working with. I think that pretty much shoots that argument down in flames before it even starts.
That said, changes to that code are rarely needed, but when they are, they are subject to the same level of rigour as the original rewrite. You get second opinions, you use the tools, you do the walkthroughs, and you test each individual option on the live kit. And that means someone competent gets in the car, goes to the client's site, and runs through everything, step by step, watching in the debugger to make sure there are no compounded errors giving the illusion of correctness. Sorry, but automated unit tests aren't even close to adequate for this work. It requires skilled engineers who know what they're doing, and no amount of process or automation is going to fix that.
Re:Refactoring (Score:2)
And? Perfection is rarely achieved the first time. Indeed, perfection is never achieved; that's one of the big lessons in iterative developent. Bugs always happen, the only question is what to do with them. When a bug is reported, I write a test to expose the bug, then I fix the bug. I may not have all the bugs, but I can be confident that certain problems will never appear.
as anyone who's worked in the field will tell you, testing with blanks is no guarantee it will work with live ammunition.
I will certainly grant that some things are so expensive to test that it's just cheaper to accept the failures that come from not testing. But anybody who's worked in the field can also tell you that if you don't even fire a few blanks, odds are low that it will work with real ammunition.
The level of testing I did at that point was way more than any set of unit tests I've ever seen.
I guess I am not getting your point. You name a lot of other quality control techniques, all of which are good. Does this make unit testing bad? No. For many cirumstances, I find it a much cheaper way to achieve a given level of quality.
The main difference is that non-automated quality control measures are very difficult to repeat cheaply. Moore's law means my unit tests, integration tests, and functional tests get 50% cheaper every 18 months. Code walkthroughs, second opinions, and manual testing track programmer salaries.
I exercised every option and every little setting, which is the most any automated test would do, if you could even write such a test in the first place. [...] You couldn't write automated tests to test the code I was working with. I think that pretty much shoots that argument down in flames before it even starts.
If you can manually test it, you can automate the test. The only question is one of cost. For pure software, the costs should be pretty low.
The problem may be in your testing techniques; retrofitting testing to existing code can be a pain, but doing test-first development is pretty painless and much less expensive then after-the-fact testing.
Some of that code is now used by thousands of clients, hundreds of times a day, and in more than two years since some of those modules went live, we haven't had a single fault report on them.
And what happens when somebody else goes to add a feature to your code? With good unit tests, an average programmer with little knowledge of your modules can make the change without breaking any existing feature. Without them, you're the only fellow who can make the changes cheaply. That's great for you, I guess, but it sucks for your employer and the colleague who gets handed the stuff when you get hit by a bus.
Re:Refactoring (Score:3, Informative)
I think you just made my point for me better than anything I've written on this thread. By your own admission, relying purely on the passing of automated tests cannot be a sufficient guarantee that your code is not crappy, which was my original contention.
I think perhaps I'm giving the wrong impression here. I do not think unit testing is bad; on the contrary, I religiously write and perform unit tests for every piece of code I create. I also prefer to have automated unit tests if the opportunity arises. My objection is to the claim that passing such unit tests -- one of the central aims of an XP approach -- is sufficient to ensure that your code is good, and reduces the need for skilled developers. My arguments are that (a) passing unit tests does not give any indication of maintainability, and (b) passing all the unit tests, while a good confidence builder, is not an absolute guarantee that requirements have been met and no bugs are lurking.
Not necessarily. If you are writing all of the code concerned, and you have control over the modularity, interfaces, etc, then yes. But much real world software development does not fall into this tidy pattern. If you have to deal with external influences, whether hardware or software, and particularly if someone else defines the interfaces (but may not keep to them perfectly themselves), then you may not be able to automate testing at all.
On the contrary. Several people have gone back and, quite independent of me, added to my original code. It was designed to be extensible, that design and the intent behind it were documented enough for people to find their way around, and they went and coded. Then they, too, ran walkthroughs on their new bits of code and unit tests of the various options, and their code, like mine, has run without reported bugs ever since.
Under the XP alternative, it's certainly true that anyone could come along, change my code and find out immediately if they'd screwed up. Whether or not they could successfully change the code and produce a new version that solved the problem is quite a different question.
One thing a clear and well-documented design is excellent for is reducing your dependence on the guy who originally wrote the code. OTOH, how does a new guy on the project who wasn't in your original development pair learn his way around? (I'm not saying it can't be done, just that it might be harder without a clearly documented overall design.)
Re:Refactoring (Score:3, Insightful)
It sounds we agree that unit tests are good but not a sufficent way to achieve high-quality code. We also agree that the key to good development is having skilled developers; processes can support or hinder them, but no ritual can turn dunces into geniuses.
(a) passing unit tests does not give any indication of maintainability
Absolutely. This is what makes understanding biological systems really hard. They don't even have unit tests, just functional tests. All the code (that is, the DNA) changes are random, and as long as the functional tests mostly pass, the product ships. (Personally, I advocate taking all those surplus COBOL programmers and giving them to the human genome project; if they can deal with hopelessly snarled 50 MLOC ERP systems, the should be able to help with all that junk DNA.)
The only thing that guarantees maintainability is maintenance by people who know they will have to keep maintaining the system. Twenty minutes into an XP project, the first unit test should pass. After that, you can think of it as being in maintance mode; unit tests are not allowed to regress, and features are continously added to the existing code base. Only maintainable code can survive this process.
(b) passing all the unit tests, while a good confidence builder, is not an absolute guarantee that requirements have been met and no bugs are lurking.
Also very true. Note that XP also requires functional tests, which are specified by the customer. Unit tests verify that the code does what the developer intended; functional tests verify that the code does what the users want. Pair programming also gives you code reviews and walkthroughs for free. For most projects, that's a high enough level of quality. But if that isn't, the XP gurus will certainly tell you to add other quality control measures, of which there are a plentitude.
Note, though, that you can never guarantee that a non-trivial system has no bugs. Each quality control measure reduces the chance that a bug will be encountered by an end user, but the cost rises exponentially for each bug found, so at some point you just have to ship.
One thing a clear and well-documented design is excellent for is reducing your dependence on the guy who originally wrote the code. OTOH, how does a new guy on the project who wasn't in your original development pair learn his way around? (I'm not saying it can't be done, just that it might be harder without a clearly documented overall design.)
Clear designs certainly increase maintainability. So does clear code. As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." And other XP heavyweights are very big on this too; Ward Cunningham, for example, makes a good case that an OO programmer should always have a thesaurus at hand, so that you can choose the best names for your objects.
But it sounds like you have a misconception about XP; pairs change frequently (generally every few hours), and knowledge is widely distributed among team members. Thus, a newbie just gets thrown into the mix, although you generally try to pair them with your more experienced people until they find their feet. Heck, one shop I know of doesn't do technical interviews anymore; they'll just bring a promising candidate in for an afternoon to pair with a few different people, doing normal work on production code. At the end of the day, both sides know exactly what they're getting into.
Of course if you have really high turnover, a shared-knowledge approach could break down, but that kind of turnover among programmers is a symptom of severe organizational problems that will likely sink any process. And if the project is put on ice and the team is disbanded, the recommended practice is to spend a final iteration tidying up loose ends and writing documentation so that they next team can take over easily.
Re:Refactoring (Score:2)
Apparently I did have a misconception about XP. :-) As mentioned elsewhere, I've only ever worked on projects claiming to work on an XP basis a couple of times. In neither case did they swap pairs around anything like that often. (Actually, I don't remember ever seeing that idea advocated particularly strongly in XP literature either, but it certainly makes sense.)
I think you'll find the idea of writing for humans not machines has been around for somewhat longer than Martin Fowler; Don Knuth might have something to say on the subject, for example... :-)
But seriously, I place very little faith in anything I read that was written by the "big names" of XP. I was browsing in the bookstore the other day on this very subject, and the old wives tales several of them recite quite sincerely in their books were staggering. (If you're interested in how long a function can really be before it gets hard to work with, try reading informed and evidentially supported works like Code Complete, and then glare at the XP evangelists who parrot that functions of more than a few lines are unusable, in spite of all evidence to the contrary.)
I'm far more interested in what people who actually use XP, and other methodologies, as part of their daily grind think. This has been an enlightening conversation (thanks!) and I shall give it due credit when forming opinions in future.
What xUnit aims for (Score:2)
More than that, there's a belief (justified or otherwise; I've got an open mind and want to get some experience before I take a stand) that xUnit allows the programmers to write the tests before writing the code, and that this "test first development" or "test driven development" leads to well designed code. (Kernighan and Pike suggest something similar in The Practice of Programming, but don't take it that far.) Interesting idea, at the very least.
Proving instead of testing (Score:1)
Re:Proving instead of testing (Score:2)
As Knuth himself said, "Be careful about using the following code -- I've only proven that it works, I haven't tested it."
-Billy
Re:What xUnit aims for (Score:2)
Tests are easy to write, and writing them helps clarify the requirements and design. Once they're written, the actual code often just falls out as obvious; even when it doesn't and I have to work for it, the tests are still a win because they tell me, automatically, when I'm finished coding: as soon as the tests all pass I'm done.
I don't use xUnit, though, because I'm using C and C++. xUnit is available for them, but it's really an inappropriate model for static languages. I wrote my own testassert package, and my friend wrote a little Python script to build a test "main()" file by scanning a bunch of files containing tests. Together they serve me very well (in fact, they're published on Sourceforge under the name of CUT, with a new version due any time).
-Billy
The biggest problem with XP (Score:5, Interesting)
The other big problem with XP is the working in pairs bit. Most developers smell bad, who wants to be stuck in a cubie with one.
Re:The biggest problem with XP (Score:2)
HEY! there's something to be said for personal hygiene, people. TAKE A SHOWER!!! Please, I beg of you!
Re:The biggest problem with XP (Score:4, Insightful)
Larry Wall tells us that the three cardinal virtues of programmers are laziness, impatience, and hubris. It would be a shame to work with a methodology that doesn't support those virtues. Happily, I am a lazy man, and I love XP. The problem you describe isn't one of laziness; it's with short-term thinking and a lack of discipline.
If your tests are good, refactoring's pretty easy; you make the change you like and let your tests tell you if you've screwed anything up. (But it helps if you use an IDE with refactoring support like IntelliJ's IDEA [intellij.com]; that takes care of all the donkey work.) If your tests aren't good, then you weren't disciplined in writing them.
If you keep things refactored and your tests are good, then adding new features is easy and low-pain. If you let your design rot and your tests don't cover anything, then adding new features takes a long time and hurts a lot. The truly lazy man will thus take the first path.
Think of it like cleaning the kitchen. The short-term lazy person will dash in, cook a meal, and leave the pans just sitting around. Next time he cooks a meal, the pans are all crusty, so it takes a long time to clean them. The master of laziness washes the dishes right away, as that is the path of minimum work.
Of course, this long-term laziness can be hard to acquire, but things like pair programming, a close team environment, and short iterations help a lot. If your partner notices your laziness right away or a team member will deal with your code next week, you're much, much less likely to write crappy code.
Re:The biggest problem with XP (Score:2)
Re:The biggest problem with XP (Score:2)
That's very true. But don't give up! It's slow getting people stated with unit tests, but once people have had a little experience with it, they see how helpful it is. Once it catches on a little, the process will snowball.
Some of my favorite tricks:
Whatever people think about XP, good unit tests make for better code and less developer stress. Until I tried XP and test-first, I never really wrote them, but now they make my life so much easier.
Another refactoring problem (Score:2)
Re:The biggest problem with XP (Score:2)
Re:The biggest problem with XP (Score:2)
If you have good tests, it's not risky at all. And good tests are fundamental to successful refactoring.
But when you discover that two projects need similar code, you basically have three paths: 1) write a good general library, 2) write some common base classes in a library and subclass in the different projects, or 3) fork the code.
For me, the decision depends on how similar the needs are between the two projects. If the designs would be pretty similar, then it's usually worth the time to do 1) or 2); going back and refactoring the old project will improve its design, too. And the more code that you share between projects, the less time you have to spend on maintenance: if a bug appears, you only have to fix it once.
nothing "extreme" about extreme programming (Score:2)
There is some benefit to the naming and the book writing that surrounds it: more programmers get exposed to the ideas. But don't expect a magic bullet: people have had a lot more experience with those techniques than their recent new clothes suggest. For some problems and environment, they work well, for others they don't. Talk to experienced programmers from the 1980's for more advice :-)
Re:nothing "extreme" about extreme programming (Score:2)
That seems wrong in a few ways.
First, although I hate the name, it is quite "extreme". In my experience, compared with teams in the same industries, XP teams are extreme in: number of tests, test coverage, frequency of code changes, frequency of design changes, speed of response to requirements changes, amount of time spent coding (vs in meetings), amount of documentation, and bug counts.
The practices also avocate certain sorts of extreme behavior, including testing everything, YAGNI, continuously changing your design, aggressively polishing your code, always programming in pairs, always telling your customers the truth, never accepting a deadline that you don't have good evidence you can't meet, and always going home on time. These aren't extreme just in their pursuit of "always" and "never", but also in that many people consider them either impossible or heretical.
Certainly, there's nothing new under the sun. And many of these techniques were invented decades ago. But some of the techniques seem to be genuinely new, or at least not written about before XP. But even if these were all old techniques, the way they are put together is fundamentally different. They reinforce one another in ways that are crucial. If you try doing refactoring without doing unit tests, you will be screwed. Pair programming provides a lot of the cohesion that make things like common code ownership, minimal documentation, and aggressive refactoring work in a team environment.
Agile methods like XP are also fundamentally different than the waterfall-derived models in their pursuit of short-cycle, high-feedback iteration. They also strive to create a balance between chaos and rigidity; most other development processes only push in the direction of rigidity. (For why this is important, see something like the book Complexity [amazon.com].)
But don't expect a magic bullet
Amen!
People looking for magic bullets don't have the discipline to pull off XP. There are no quick fixes; the construction of good software requires skill, discipline, and patience no matter what method you use to build it. The method you pick can't provide those qualities; at best, it can reduce the chaos enough for you to improve them.
Re:nothing "extreme" about extreme programming (Score:2)
Industry is not the only place where programming happens. In fact, industry is far behind the curve when it comes to new methodologies.
XP is very close to the entire approach taken to programming by people in the Smalltalk and Lisp communities, practiced at least since the early 1980's in numerous academic and research labs.
Re:You should read XP Explained before commenting. (Score:2)
Sorry, but I disagree. XP is pretty much how a lot of Lisp, Smalltalk, and similar communities have worked for a long time, using pretty much the whole of what is now called XP, not just bits and pieces. That's not surprising: those communities face rapidly changing requirements, they often have easy access to their end users, and they are usually highly qualified and trained. And that's the community Kent Beck came from; he is just trying to popularize those practices and ideas among non-Smalltalk users.
I have my doubts that that is such a good idea. Languages like C++ and Java were designed for non-XP development processes. Neither the languages nor the tools are up to the needs of XP. Trying to use them for XP is like trying to use a wrench as a hammer. But, then, industry has been trying to use wrenches as hammers for as long as we have had programming as a profession.
Re:Java on XP ? (Score:1, Insightful)
Then again, perhaps I`m a little old for it...I certainly dislike the way everything is being spelt phonetically now...Lyke weer all Stupidue phucking hip-hop fann boyz now or sum`thin`...
Re:Java on XP ? (Score:2)
Re:Java on XP ? (Score:1)
It's the Current Marketing Kitsch (Score:2)
In 1998, the buzzwords all involved the Internet.
In 1999, the buzz was all about UNIX and Linux.
In 2000, Apple announced Mac OS X, which was a pun on the point that the new OS would run a form of BSD UNIX and that this was version 10, as in the Roman numeral. (There may have been an OS named "OS 10" elsewhere that could've led to trademark suits, too.) The new interface was named "Aqua."
Microsoft, working on its "Whistler" OS successor, later announced that it would slap on a Fisher-Pricey interface on its Whistler OS and name the interface "Luna." Later, they would announce that the new OS would be named Windows XP.
The industry names their products with respectively confusing names thereafter.
I think we can blame Microsoft on helping to muddy the waters once again on this one to confuse things mostly with OS X and other UNIXes.
Re:Java on XP ? (Score:1)
It's simple. A certain big company [jera.com] knew that a backwater software development methodology would never cause too much confusion for the consumer after their marketing goons kicked into gear.
Re:Java is not unlike C++ (Score:1)
However, in C++ you can't just see what methods a particular object can handle, or load a given implementation of an interface based on a String you got from a properties file or something.
But the best that I have used in terms of dynamicaless has got to be Objective-C.
In Java, you can have a reference of type Object, which will point to any kind of object. But you can't really do anything with it, other then pass it around and store it. You can't call methods on it without figuring out what type it is.
In Objective-C, you can call those methods. If the type implements them, then great. If not, then an exception is thrown. And all kinds of other cool things. However, the syntax is weird <smile> as if that matters </smile>:
Instead of
object.method( arg1, arg2 );
It's
[object method:arg1 nameOfArg2: arg2];
All the argument have names, which makes things easier when you can't remember what order they go in some methods.
Re:Java is not unlike C++ (Score:2)
In Objective-C, you can call those methods.
???
How is that significantly different from java? Cant you just cast the Object to whatever you like, and if it doesnt match up with the new cast, it gets an exception thrown??
Re:Java is not unlike C++ (Score:1)
Re:Java is not unlike C++ (Score:2)
Actually compiled languages are kinda silly when you could hand craft your code in assembler and not have to waste all those cpu cycles compiling and linking over and over as you develop:)
Apache has a nice page on common myths surrounding Perl web applications here [apache.org]
Performance in a particular language depends on the task and more importantly the skill of the programmer. Also, usually the most import factor is developer time.
Take a second and review this paper on An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl for a search/string-processing program [ttp] (PDF sorry)
Conclusion
Designing and writing programs in Perl, Python, Rexx, or Tcl takes half as much time as writing in C, C++, or Java and the resulting program is only half as long.
No differences in program reliability between the lanuage groups.
Typical memory consumption is about twice that of C/C++ but Java programs was another factor level higher.
Re:Java is not unlike C++ (Score:2)
Re:Java is not unlike C++ (Score:2)
Objection, Your Honour. That's hardly a fair test of languages in general. As you point out yourself, these things are inevitably task-specific, and many interpreted/scripting languages have powerful built-in support for string processing, so of course they come out on top. Would you like to see the results of my empirical comparison of C++, Java, VB and Perl for creating a realistic GUI front-end or a high-performance maths engine, now? :-)
Re:Java is not unlike C++ (Score:2)
you're right about performance not mattering most of the time. it does matter some of the time, though, and then it's usually memory performance.
and if you had a project with just one or two people coding i don't think it would matter which language you chose to work in.
but in my experience perl is a disaster for projects with more than 10 people. i'm sure there are exceptions or you won't agree, but that's my experience.
the program being "half as long" is not necessarily a good thing. it depends what information you cut out. if it's half as long because you used powerful langauge features to reduce the number of program instructions then that's probably a good thing.
but if it's half as long because you cut out type declaration then what are you really saving? you type less, but someone reading your program also has less to go on when they figure it out.
this is why in large projects perl is just not viable: it's not possible to isolate program error effects from one component from spilling all over the application and turning up in unexpected places. you then spend hours and hours debugging your code, or more probably, bothering the person who wrote some section or other to have them explain it to you since it's unreadable. hopefully they still work for the company.
some people answer to this that you can just do ever more testing, and that your unit tests will eventually catch all the errors.
at that point i ask you, isn't a type declaration which is checked by your compiler exactly that? a little test? a little check?
so it seems that with perl you throw out the compiler checking and then have to write all the same checks by hand all over again.
i like langauges like perl because of the powerful features that can reduce 100 lines of code to 10. but please don't take away from me the 10-20 lines that were declarative, that told me what was what and how it fit together. that information is for *me*, it's not really for the compiler. cutting out the type definitions is a bad thing.
java also has a fairly powerful library available, comparable to perls most of the time, and depending on the application either better or worse than perl's. but it also is a strongly typed langauge, and in my view, that makes it viable for projects with many people.
C++ is a different story. sometimes i think you do need to code in a low level langauge to get the performance you want--the linux OS will never be written in perl. but for general applications i wouldn't choose it, however, it's a good systems langauge programming envirnoment.
i still write perl programs--when i have a little one-off just for me, or to fix up a trashed file, or parse some data out of some stream, or something, i turn to perl for these quick little one-offs.
in fact i found a great use of perl is that it's the perfect langauge for running through all my
the languages are not in competition really, just different purposed. java is for large scale application development. perl is for quick and dirty one-off applications. C++ is for systems programming.
a good developer, in my view, should be comfortable with all three (or an equivalent set of three).
Re:uh, the article is about eXtreme Programming (Score:1)