Having just read it over the past two days, I found it to be a very approachable explanation of XP practices. Most XP sites I've read are written by fanatics for fanatics, which turns me off. This actually went through the best practices and explained XP very simply.
Personally, I think that this book is a good resource on XP practices in general. The Perl side of it is primarily within the examples, similar to how Design Patterns by the Gang of Four is a book on programming theory that uses C++, Smalltalk, and Java in their examples.
I would strongly recommend this book to everyone, even if only to see how the other side lives.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
I expect to see a lot of 1337 programmers doing rad tricks like mangling the symbol table and installing source filters. I also expect a very loud heavy metal soundtrack, with lots of highlight reels of programmers bailing from twisted stack dumps, compiler errors, seg faults, and other stunts. Of course, I am still waiting for the EXTREME BRAIN**** DVD.
Ok, maybe not -- I'm just not an XP fan. It may be right for some people and in some orgs, but often it is just another "Best Practice", and I always follow the legendary advice, "Beware the Greeks Bearing Gifts", I mean, err "Beware the Academics (UPDATE: I left out Overpaid Consultants!) Bringing Best Practices". Having attended numerous XP lectures, many of which from folks buddy-buddy with Kent Beck, and often seeing XP fail, I have grown much distaste for such a trend. It is full of sound and fury... and buzzword compliance!
Perl may be decently suited for XP (seeing it is very flexible and rapid development-like from the start), but the nature of having more breakable interfaces (less datatypes and soft OO), may make this even more of a liability than normal XP, which I equate to walking in a minefield most of the time. With Perl, it would be, IMHO, like playing tackle football in a minefield.
| [reply] |
I expect to see a lot of 1337 programmers doing rad tricks like mangling the symbol table and installing source filters. I also expect a very loud heavy metal soundtrack, with lots of highlight reels of programmers bailing from twisted stack dumps, compiler errors, seg faults, and other stunts.
Then you'll be wrong. The "extreme" in XP not about doing anything dangerous or radical. Quite the opposite. It's about taking existing good practices and taking them to the extreme.
Ok, maybe not -- I'm just not an XP fan. It may be right for some people and in some orgs, but often it is just another "Best Practice", and I always follow the legendary advice, "Beware the Greeks Bearing Gifts", I mean, err "Be Ware the Academics Bringing Best Practices". Having attended numerous XP lectures, many of which from folks buddy-buddy with Kent Beck, and often seeing XP fail, I have grown much distaste for such a trend. It is full of sound and fury... and buzzword compliance!
Well I'm certainly not a buzzword compliance sort of chap (otherwise I wouldn't be coding Perl for most of my day :-). There is, as they say, no silver bullet. I've never met Kent Beck, Ron Jeffries or anybody involved in the start of XP, SCRUM, FDD or any other agile development methodology.
However I've found following the practices in XP, and taking a more lean/agile approach in software development has resulted in better software and better customer relationships. All the people I know who have looked at agile/XP techniques seriously have had similar results. All the places I know where XP has "failed" have only been playing lip service to the XP practices.
I've found little sound and fury. I've found lots of people doing their best to build software more effectively, and exploring different techniques to make that happen. As ever YMMV.
I'm not sure what the "academics" jibe is about since the agile movement has come from the practitioner end of the world (not that I have anything against academics :-)
Perl may be decently suited for XP (seeing it is very flexible and rapid development-like from the start), but the nature of having more breakable interfaces (less datatypes and soft OO), may make this even more of a liability than normal XP, which I equate to walking in a minefield most of the time. With Perl, it would be, IMHO, like playing tackle football in a minefield.
Actually most peoples experience seems to be the opposite from yours. More dynamic languages seem more, not less, useful with agile methodologies. The advantages that more 'strict' languages give you are compensated for by other aspects of the development process (e.g. better test suites) so the flexibility that dynamic languages give you are even more effective.
I'll be the first to admit that XP doesn't solve all problems or is suitable for all situations. For example I'm having problems integrating agile practices with the processes and artefacts of traditional user-centric design.
Now, if you've got some specific criticisms of the content of Robert's book fine. Write them down and everybody can learn from that. Robert's put it up for feedback after all!
If you've seen XP fail that's great. Talk about why and how and everybody can figure out how to build a better development process that won't fail the next time around.
Implying, if only briefly, that XP is "a lot of 1337 programmers doing rad tricks" or about writing test that "verify 1 + 1 = 2" might be a good debating technique, but it's not true and helps nobody.
| [reply] |