Slashdot Mirror
Go Extreme, Programmatically Speaking
raelity writes: "The O'Reilly Network is featuring An Introduction to Extreme Programming, by Chromatic (of Slashdot and PerlMonks fame). 'The central tenet is, "Find the essential elements of creating good software, do them all of the time, and discard everything else." Programmers should program and make schedule estimates. Managers should make business decisions. Customers should choose the features they want and rank them by importance.'"
But where XP can help recover from this is that the atmosphere for testing is still there. When an integration or enduser break happens, the inputs can then go back to the programmer to create a new test case and fix the code by making that test case do what should have been done.
So its still possible to have broken XP code, but at the same time, the fixing of it should also be easy...
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
A brief response:
1. Irrelevant. Describe the methodology and what it means and achieves. Call it XP right through this. Sell it well enough and when they do find out what XP stands for, they'll only find it amusing, not off-putting.
2. We should all be doing these things, but I've never seen them done properly by someone that hasn't read XP books. And I don't know many people that have.
3. I am continually annoyed, scared and depressed by the comments on designing up front. For $40m projects doing air traffic control then sure, you want some pretty sweet documentation. But for 98% of business systems you need enough to get to your first deliverable. And that's not much. The design needs to accommodate the immediate requirements, and if you follow design patterns and don't actually close off expansion capability, then you can adapt to the changes needed for further deliverables. XP isn't about diving on in and coding, it's about thinking how to deliver what is needed. And if future capabilities aren't needed now, just don't spend time writing them - it's quick, cheap and easy to change code.
4. Well written code is far more useful to me than bad documentation. And in a business environment, working on code more than a couple of months old, ALL documentation is bad documentation - it is invariably out of date, imprecise and often irrelevant. Whereas the code tells you very accurately what is happening.
This doesn't mean the occasional class diagram or process flow wont help, but any member of the development team should be capable of drawing them up on a whiteboard without prompting, and that's the correct place for them. Documentation that isn't updated but is referred to will cause more bugs than having none in the first place.
Bear in mind of course that if you're properly following XP, and you write your unit tests to the same standard that you adhere to for your live code, then the unit tests provide a fantastic resource for seeing example usage of the live code. And examples are immensely more useful than documents.
5. You put forward a very negative and close-minded view. I'm often irritable, I swear at my computer let alone other people, I am very opinionated and disagreeable and I love an argument. Worryingly, so is the guy I've been pairing with for the past few weeks. And yet we're now turning out code much better than either of us managed individually, and we're working very efficiently. And we're also very keen to continue pairing because there are so many benefits it would be silly to stop. If someone's personality prevents them pairing them it's almost certainly going to prevent them working with the team as well, in which case most businesses would be better off with someone else - a good team provides more than the sum of its components.
I'm sure a lot of people will keep using XP, and that a lot wont go near it. And I'm convinced that many of the practices should be kept. But I think discounting it because you don't like the name and are scared of pairing with someone else is highly unprofessional and closed minded.
~Cederic
XP is an interesting (and controversial) methodology that has proven its usefulness in real projects, and it is nice to see it covered on slashdot. It is gaining acceptance in the software industry. One indication of this is the number of talks on XP at the SD2001 West conference in San Jose 8-12 April.
However, decent references are sorely missing from this story, like for example
the book by Kent Beck and one of the more comprehensive web sites, www.xprogramming.com by Ron Jeffries, with links to a lot of other resources on XP.
Is anybody else sick and fscking tired of reading about Extreme Programming on SlashDot.
g ra mming
http://slashdot.org/search.pl?query=Extreme+Pro
Variations on the same article over and over and over and over and over again. I get the message already, and I'm not going to switch just because it's advertised here three times a week, so kindly *stop it already*.
Is this post not nifty? Sluggy Freelance. Worshi
So, they're saying, "Figure out what's good and do it," huh? Well, it's good advice, but isn't it pretty much what we're supposed to in the first place?
I've never had someone come up to me and say "Write good code!"
I always thought that the "write good code" statement was implicit. If I'm writing code in any serious fashion, it's going to be the best I can do.
Maybe everyone else has been writing bad code intentionally all this time... They just needed to be told to do a good job! "Well, no one ever SAID 'Write good code' to me..."
Most comments are pointing out that XP is yet another management buzzword or it's just stating the obvious. Well, it's neither. XP stands against all the principles touted by the waterfall model or the Rational Unified process and shite like that. XP is basically saying "toss out that copy of Rational Rose because you ain't gonna need it". If it doesn't make your job easier (and Rational Rose doesn't, believe me) toss it out. If you're already building five classes to parse a simple parameters file toss it out because you ain't gonna need it. XP points out (quite accurately) that the design for change is only useful if we allow extendibility in the right places. Unfortunately this requires you to analyze your problem domain beyond what's needed to ship your product and most of the time you'll still get it wrong. You'll get it worong because you don't have a crystal ball. You can't tell what the customer will want next. This way you eliminate the whole code design circus and end up with simple code that does what it's supposed to do, no more, no less.
One of the most important aspects of XP is unit testing. XP recommends that unit tests be written before the code that's supposed to pass those tests. This is more important than you think for two reasons.
Reason one: how are you supposed to develop your code if you don't know how to test it? When you write your unit tests you gain insight into the exact functionality of your code.
Reason number two: If you write your tests after you develop the code your tests will most likely only test the scenarios you considered when you were writing the code. Your tests will most liekely be incomplete because they'll have a slant towards your implementation.
Coding in pairs is probably the most prominent and the most controversial aspect of the system. It's important to realise the benefits of pair programming though. No code ownership means people can't get territorial about their code so everyone is free to change it when they need to change it. I've seen shops where changing John's code was considered politically incorrect and often John would take the issue personally. In other words if John wrote the message dispatcher John and John alone would decide on it's shape, form and future directions. XP essentially says that the hypothetical John can no longer pee around "his" piece of code and keep it as a guarded secret because John is no longer the sole developer of the message dispatcher. If John gets territorial about his work, John gets moved on to do something else and somebody else takes over until they start growing attached to the code again. Lather, rinse, repeat.
Besides code ownership and territorial programmers the other issue that XP takes on is coding primadonnas. Most software shops have a standard (sad) working model. One self promoted primadonna coding 70% of the application including the critical subsystems and the other twenty developers working around the edges "helping" the primadonna and trying hard not to get in her way. Our primadonna often isn't even the best coder on the team but surely is the most bullish and opinionated and thus grabs all the exciting work. Everyone else is just supposed to feel inferior and work on some tiny pet project of their own. This is not only grossly underutilises the rest of the team but usually at some point puts the project in jeopardy because the primadonna has now found another company to prey on. Project "gurus" have mushroomed throughout this industry and weeding them out may prove challenging. XP offers a very radical albeit a very promising way of achieving that.
This comment is growing a little long now so I'll shut up at this point. I hope this offers some enlightenment to those who keep on saying that XP is just another waterfall mutilation. It's not. It's a hackers methodology. On the side not however, I to have an issue with the name and the accronym. It's just juvenile.
Your pizza just the way you ought to have it.
--
KMSMA (WWBD?)