Slashdot Mirror
Extreme Programming Installed
The Scoop Last year's Extreme Programming Explained was a manifesto of sorts. Wouldn't it be nice if customers, management, and programmers could work together to produce good software on schedule and under budget? If planning, peer review, testing, and design are good, why not do them all the time? It even put forth the radical notion that customers should set business value while programmers create -- and revise -- technical schedules.
Yet another 'silver bullet' Fred Brooks debunked years ago? The authors of Extreme Programming Installed disagree. The book breaks XP into workable chunks, hanging flesh on the bones of Kent Beck's manifesto. It explains each element of XP in turn, based on the authors' personal and collective experiences.
For example, the Iteration Planning chapter describes planning meetings. The customer presents stories, the developers break the stories into tasks, and individual programmers estimate and sign up for tasks. Each element has further detail on best practices and potential traps. Finally, the chapter describes an average meeting.
What's to Like? As with other titles in the series, the text is clear and easy to read. The short chapters have no fluff, saying only what's needed. Concise explanations and a gentle, conversational tone add up to a book that can be finished in an afternoon.This book is the most practical of the series so far. Drawing on personal experiences and data gleaned from early adopters, the authors distill XP practices into their purest and most essential forms. Anecdotes from programmers in the trenches line the pages. Though everyone practices the processes slightly differently, a clear picture begins to emerge.
Though listed in the table of contents as "bonus tracks," the last 11 chapters may prove the most valuable. Each track addresses a common concern or criticism of XP, from "Who do you blame when something goes wrong?" to "How do you write unit tests for a GUI?" and "You can't possibly make accurate estimates." This won't satisfy all the nay-sayers, but it adds a healthy dose of reality.
What's to Consider? The testing and refactoring sections, needing the most explanation, have a strong Smalltalk bias. While these chapters have strong supporting text, a decent programmer unfamiliar with the language will have to invest extra time to understand the examples fully. This is the most detailed portion of the book, and may be the hardest to read.While some readers may like the open-ended nature of the presented techniques, others, familiar with more formal development processes, will want authoritative proclamations. XP actually installed, argue the authors, depends on the nature of the task and the team. The controversial axiom of embracing change by continually performing a certain few practices while discarding the rest, will raise some blood pressures. Clearly, this is not for the faint of heart.
Developers and managers interested in the whys of XP would do well to read Extreme Programming Explained instead. Though the authors present a brief business case for the process, most of the text assumes the reader has already decided to install it. Customers receive more text (a few chapters), though there's clearly room for an expanded treatment of their roles and responsibilities.
The Summary Extreme Programming Installed will not silence the critics, but it makes great progress in showing how XP can work, in the right places. Beyond that, it demonstrates the flexibility of the approach, with numerous real-world examples. This book deserves a place next to Beck's manifesto, showing off XP as it's actually practiced. Table of Contents- Extreme Programming
- The Circle of Life
- On-Site Customer
- User Stories
- Acceptance Tests
- Story Estimation
- Small Releases
- Customer Defines Release
- Iteration Planning
- Quick Design Session
- Programming
- Pair Programming
- Unit Tests
- Test First, by Intention
- Releasing Changes
- Do or Do Not
- Experience Improves Estimates
- Resources, Scope, Quality, Time
- Steering
- Steering the Iteration
- Steering the Release
- Handling Defects
- Conclusion
- We'll Try
- How to Estimate Anything
- Infrastructure
- It's Chet's Fault
- Balancing Hopes and Fears
- Testing Improves Code
- XPer Tries Java
- A Java Perspective
- A True Story
- Estimates and Promises
- Everything That Could Possibly Break
You can Purchase this book at ThinkGeek.
We've been doing a lot of it; pair programming and refactoring are the biggest parts for us.
Pair programming is lame, IMHO. 2 people will tend to either wander away from the programming topic, as sitting and watchng programming happen can never be as involving as actually programming. Also, 2 or more people tend to bicker over editor styles, code quirks (comment format and such) that gets overlooked during a code review.
Refactoring is a good idea when used sparingly, I think. Everyone complains about cruft but rewriting things to make it go away is seen as wasteful. YMMV but we've refactored a few things and had it work for the better.
Still, I think the majority of the XP "movement" is an effort to change the status quo by being, well, extreme, like asking your mom if you can stay out till 3am if you only want to stay out till midnight.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
That's a myth. Sure, there are a lot of people who think they're smarter than anyone who went before (or anyone else, period) but most of those people are wrong. What do you think, that somehow people from past generations were uniformly stupider than those in the current generation? Do you believe that you just happened to be lucky enough to be born during a period of rapid evolution for the human species?
No, 'fraid not. Older programmers are not, statistically speaking, stupider than younger ones. They may have learned programming when the state of the art was far behind where it is today, but their capacity for learning is no less. For every old dog I've known who couldn't or wouldn't learn new tricks, I've met at least two young pups who think they know everything there is to know after two years (or less) doing easy types of programming. The difference is that experience always counts for something. It may not count as much as a solid grounding in the latest tools and techniques, but everyone picks up some sort of useful tricks in a couple of decades of real work - in any field, not just programming.
The point, as so many other posters have made, is that it's at least as foolish for you to dismiss the concerns of the old hands as it would be for them to dismiss XP, without examining the essentials. They have good reasons to be skeptical. Anyone who has been in this business has seen people talk about all sorts of methodologies exactly the same way folks here are talking about XP now, and most of the talk has turned out to be just hot air. If you want to convince those people of how great XP is you'll have to address their concerns head-on...and you do need to convince them. Those skeptics are going to be or in decision-making positions for a good many years yet, as you try to deploy XP, and if their concerns are not addressed it will be impossible to develop the spirit that is necessary for XP to work. As long as you keep making flippant remarks about learning capacity, neither they nor people your own age will want to get involved with a methodology that requires them to work closely with you.
BTW, since it does seem slightly relevant, I'm 35. This would seem to put me right between the "old dogs" and the "young pups".
I think there's a growing recognition in the industry that trying to turn good engineers into managers is a dumb idea. What you end up doing is depriving yourself of a good engineer's technical contributions, and getting yourself a medium-to-lousy manager in return (because the optimal temperaments for top-level developers and for managers are almost opposite). This recognition is a good thing.
This also brings me to another point I've been pondering. Our love for egalitarian solutions seems to have become an actual phobia about all forms of hierarchy. Just look at how client/server has given way to P2P. Much of the appeal of XP seems to be that the pair programming approach replaces a more traditional approach in which senior engineers look over the shoulders of junior ones to keep them out of the weeds. Just say those words a couple of times...senior, junior...in today's intellectual climate even the words themselves seem slightly taboo. People love the idea of doing away with such distinctions, even though they've proven very useful. I have to wonder whether this is in part because, with the explosion of the Internet and e-everything, so many shops just don't have any senior engineers and they have to find methodologies that work without them. To be fair, I also wonder if some of the resistance to methodologies like XP is rooted in senior engineers who thoroughly enjoy being "on top" in the traditional model and worry about losing that. I wonder, and I'm sure there's a grain of truth there, but I don't think it's as much of a factor as distrust of "magic bullet" salesmen. I still think that, in an organization that does have the benefit of experienced technical leadership, pairwise programming might be a costly solution to a minor or nonexistent problem.
Again, you may have an answer to this, but the objection - in your colleagues' minds, not necessarily in mine - must be overcome if you want XP to be adopted. You can't just say "read the book" either. You - not "you" specifically but "you" referring to all the XP proponents out there - need to learn how to be effective XP advocates in your own right, and in general the way people have been going about it on this thread so far is definitely not going to be very effective in the workplace. The first thing an effective advocate has to do is learn and accept and admit the limitations and drawbacks of the thing they're advocating, so that they don't immediately lose credibility with people who are accustomed to questioning things and looking for weaknesses. After all, questioning things and looking for weakness are traits we encourage in developers.
Slashdot - News for Herds. Stuff that Splatters.
The planning meetings, stories and tasks keep everyone on track. The pair programming makes the code better and teaches everyone about the code.
It is working out far better than our previous development methodology, which I will call "Extreme Failure".
Why does it have to be extreme? I'd like to see Programming that might kill you and throw your body off a bridge.
No boom today. Boom tomorrow. There's always a boom tomorrow. - Cmdr. Susan Ivanova
the supposed way to go is not to be looking ahead to the next problem
Yeah, this bugged me, too.
The way they talk about it is in pretty absolute terms. Don't look ahead, just focus on the immediate concern, etc, etc. It sounds ridiculous, and when you take it literally, it is ridiculous.
But after a little while, I began to see the problem they were trying to address. It's very easy to say things like "well since we need to display one graph, we should build a whole graphing framework, as we'll probably need to do more graphs eventually." And then you go off and spend a month building a (very nice, very solid) graphing framework for your one graph. But it was fun and interesting and the Right Way To Do Graphing, so you feel good about your work. And once they ask for more graphs, you'll be golden.
But then it turns out that nobody ever asks for more graphs, and so your nice framework never gets used. Worse, people don't use the program much because it's missing features that they need, features that you could have added in that month. So the project gets cancelled and your code goes to waste.
So their point is not don't do work that you need 15 minutes from now but more like don't do work that you won't need for a month. You just figure out what you need to get this version finished and code that. That doesn't mean writing shoddy code to get it out the door, of course; you write good, solid stuff, but nothing more than you need. When the next revision comes, then code that then.
If you haven't experienced refactoring, this still seems ridiculous. But if you already have an lot of unit tests and functional tests, you become confident that you can improve your design incrementally and still have everything work. Which means that painting yourself into a corner is not the problem that it was before.
Personally, I am still getting used to this. But so far it has worked pretty well.
A major shortfall that I've seen in XP is that it requires that 'all be equal' in skill and understanding. A constant refactoring of existing code requires that all participants be on the same foot and have access to all the same facts.
That's not true in my experience. It does require programmers to have a semi-sane understanding of how good they are, though. And it requires that everybody have a fair bit of team spirit. Novices must be smart enough to know that they should not be doing major redesign without talking it over with the team first. (And really, the same goes for the experts.)
1. Tightly Focused team, with no distractions from other priorities. (I typically work on 2-3 projects at a time, each at various states. My scheduling precludes any 'shared programming' time.)
This isn't necessarily true, but XP does require a lot of communication between developers on a project. Pair programming and a shared project room are good ways to do this. Solo developers communicating by email is a very bad way to do it; if you're in that condition, XP is a bad choice. So if you have to work on multiple projects in an XP context, you have to rigidly schedule things so that, e.g., all the work on Project A happens in the mornings, and all work on Project B happens in the afternoons.
I'll argue the other way: The lowest skilled team member will drag the team and the project down.
It depends on what you mean by lowest skilled. If you mean "fresh out of school with little experience", then you try to make sure that the novice gets paired up with senior developers for a while. At first, they'll have little to contribute (e.g., "You missed a semicolon") but quickly they become more productive.
If, on the other hand, you mean "never likely to be a good programmer", then yes, they are bad for the project and should be fired. But even in this case, pair programming, good unit tests, shared code ownership, and strong version control limit the damage one rogue idiot can do much more than on a project that doesn't use these techniques.
3. Well targeted goals.
I agree that this is good to have, but it's much less of a problem on an XP project than, say, a traditional Waterfall lifecycle project. A frequent release schedule (XP recommends every 1-3 weeks) is the key. Everybody gets together and sets the goals for the first version. In a couple of weeks, everybody gets together and says "Oh! Now we see that we should really be going Y instead of X" and so you code the next revision that way. When goals are poorly understood, Evolutionary Delivery lifecycles are great for reducing risk.
The problem with books like these is that I cannot tell at whom they are aimed.
Beck's book is aimed at all members of a development team, for the simple fact that XP is a team-oriented approach. It covers a broad range of areas because he feels that the value comes not in the indivdual pieces but in the way they reinforce one another. E.g., refactoring without good unit tests is dangerous. Common code ownership is very risky without the good communication promoted pair programming. Limited planning is very risky without short release cycles. And so on.
Someone who is an experienced software manager is unlikely to need to an all-encompassing book like XP.
There are two problems with this statement. One is the implied suggestion that an overwhelming majority of software managers are so experienced that they know the basics solidly. The second is that there is some all-encompassing framework that is so well established that all good managers share the same view of software development.
The truth is that neither is true. I'm not sure where you work, but I've been doing development for 15 years, and I'd say that good project managers, well versed in all important aspects of developing software are the exception, not the rule.
And as to the notion that the foundations of our discipline are so well-settled and obvious that a book with a broad view of the process is useless, I can only laugh. As a developer and the son of a developer, I can assure you that this isn't true. The goals, resources, methods, tools, and methodologies have all changed relentlessly, and that won't stop until Moore's law gives out.
If you've got the twenty-plus years of experience that you claim, you know that almost everything thought of as "fundamental" thirty years ago is different now, and you need only pick up a few CS textbooks to verify that. Even today, a large percentage of software development projects fail utterly, suggesting that, as a profession, we don't really have our acts together.
So bravo for books that are broad in scope! XP may or may not suit your projects (and indeed, I would be surprised to see it working well in an embedded-systems context), at least Beck took a broad look at the process and challenged some sacred cows. I don't buy all of what he's selling, but I found it valuable to read his book.
Actually, that's not an ad hominem attack. An ad hominem attack is one where you attack the arguer on the basis of something both personal and irrelevant. For example, calling you ugly and smelly would be an ad hominem attack. The claim that you have an axe to grind, however, may be personal but it's sure not irrelevant.
And really, the guy has a point. Your first post in this thread is titled "New Age Programming B.S."; it's a full-tilt screed against a book you obviously haven't read. Why would you do that?
Is it because you know the author to be a charlatan and a cad? Is it because, although you didn't read the book on XP, you did try its techniques faithfully and found them not to work? Is it because you are the author of a study on XP that shows it to be a fraud? If so, you never mentioned it.
So when somebody posts a rant about a book that he hasn't read and doesn't back his frothing up with some other justification, it is reasonable to presume that you indeed do have an axe to grind.
Indeed, I find it really weird that of all the negative posts in this thread, almost none of them are from people who have actually tried the XP methods on a project. It seems like there's a lot of axe-grinding going on, although that's nothing new for slashdot.
Yeah, but unit tests are probably the most fundamental concept to XP. Throwing them away is not "the tiniest deviation" - you're completely destroying the feedback loop at the heart of the methodology.
:-)
Sure, he did make that assumption backwards from you said - but I fail to see how "things were constantly being broken" and "they adhered to unit testing" are compatible.
Not that I know shit. Shrug.
--
http://www.gimbo.org.uk/
If your partner is humming and clipping his nails, he's being a lousy partner. The 'watching' half of the pair is not just sitting there passively; he should be actively participating, keeping track of what has to be done next to keep the rest of the system consistent with the changes you're making now, etc.
You mention trouble with distractions in the office. This is actually one of the values of pair programming that isn't immediately obvious: It's actually a great focuser and shield against distractions. Coworkers who want to pull you into a discussion about last night's must-see-TV are far less likely to try to do so when you're working with a partner. And you're far more likely to be disciplined about ignoring these things, yourself. It's also helped me that I treat pair programming sessions every bit as formally as I do meetings: My partner and I set a time, and come up with an agenda in advance of the actual session.
You guys are all on a hair-trigger with the anti-machoism.
I don't think it qualifies as being in hair-trigger mode to respond strongly to someone who proclaims that "the only programmer I'll allow to watch over my shoulder is a dead programmer". If you want calm, measured responses, you should probably speak in a calm, measured manner yourself.
Each week you vote someone off the team...
There is *ALOT* of discussion on Extreme Programming over at wiki...
http://c2.com/cgi/wiki
If you aren't already familiar with wiki - do so. Comments posted there generally have *ALOT* more relevance than most of the whiney, dumb-ass trolls you see all too often around here!
It can sometimes be difficult to navigate, and sometimes the concepts flow as smoothly as a pile of boulders - but it's definitely something to check out if you haven't already...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I`ve read the XP Explained book of Kent Beck, and I can really advise everybody to get it. That one was a fast read, in fact it reads so fast that you stop thinking about the concepts that are presented, because they seem so natural to do (in a perfect world ofcourse). Reading the tiny review on his successor, this book seems like a poor sequel to the original. I`ll try to fetch it from my local library when it comes available, because those anecdotes are what really sticks into your mind when it comes to remembering the important stuff, but I`m not sure if it can serve me. I`m all for the practical nature of things, and XP Explained`s theoretical principles was even boring at times, so revisiting the same deal in a practical context might be interesting to read, but maybe not to buy.
Besides I think that to really succeed in working with XP, you have to reinvent it yourself in your own situation with your own needs and peculiarities. This book can sure give you some bright ideas, but it`s not something you should depend on.
With great power comes great electricity bills.
I've read some stuff on XP programming and it sounds intersestings. I'm itching to give it a try, however, I do a lot of threaded and GUI programming, which XP programmers readily admit doesn't work well with the XP methodology. Threading, in the proper context and with enough experience, is one of the great things about java. If they can't find a way to make it work with threading, XP has some serious flaws.
You want corn? I give you corn.
I may be wrong, but I'm never uncertain.
Basically, everyone walked over everyone else's code, things never once worked properly. Without any sense of forward thought, basically the project went to a standstill.
The situation wasn't helped by the fact that one or two incompetent programmers on the team destroys the whole project. My GF was one of the few intelligent coders on the team, largely the reason that any forward progress was made (as vague as progress was). However, pretty much every day, someone stupid would destroy her code under the guise of XP's constant state of refactoring.
It cause numerous conflicts between the programmers and a few people quit, including my GF.
It's so convenient to paint things in black and white. Either management are incurably ignorant, hence nothing will save them, or they are devine oracles, and they already know everything. The ignorant are too stupid to learn, the wise already know everything, therefore learning new things is pointless.
There's nothing in your reasoning that precludes it from generalising to all fields, and allowing us to reach the absurd conclusion that noone needs to read.
I can understand the folly of touting a book or methodology as an instant cure-all, but in the high tech industry, dismissing new ideas because you think that you already "know it all" is hardly a recipe for success.
The first big unique thing about XP is its rejection of the "exponential cost curve" taught in most software engineering classes. Instead of trying to anticipate future requirements and design accordingly, XP advocates keeping the code simple, flexible, and solidly regression-testable, so that the cost of changing code is always cheap. In my experience, this has proven a really good idea.
The other unique thing about XP is that it gives structural support to the so-called "good habits" of software engineering, rather than relying on exceptional programmers to (hopefully) implement them. Over-the-shoulder coding is a wonderful technique that I at least hadn't tried before (your coding buddy doesn't even have to be a particularly strong coder, and it still works very well). The continuous test cycles and writing tests before code are not new, but the discipline of implementing them is most welcome. Short iterations with a focus on business value is practically unheard of -- instead, the focus is usually on getting a complete spec before moving to a rigid (and thus usually brittle) implementation, etc.
Of course XP isn't unique in one sense: some of the best programmers I've known already use these techniques in their own work. But, much as How to Win Friends and Influence People doesn't tell you anything you didn't already know, it's useful to have it all in one place.
Take a closer look at XP if you haven't; what your post points out to me is that, like other fad processes, people will probably rush to implement XP, miss the point, and denounce it as a fad instead of looking for the core contributions to the art.
Clearly, you didn't read the book.
Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.
He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.
Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.
So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.
I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.
XP is about attitude. Just as there is a vast difference between agressive and passive error checking/handling, the entire XP philosophy is centered around agressive programming.
You don't code until you need to code it. (No that doesn't mean you don't do a proper design) You refactor code and design as soon as you run into delays or problems. This way you avoid cruft that builds up. You are under constant code review (when programming in partners). You get exposed to the whole system and not just one small section. Interestingly many of the XP practices go against what traditional SE teaches.
http://www.xprogramming.com/ - has a good overview of the processes and atmosphere that XP creates. Check out the XP Practices in particular.
I've tried implementing some of these practices myself in personal programming. I can tell you it takes more engery but so far I like what I'm seeing from my progress. I'd like to see how effective pair programming can be as well. I've done a bit of this at work but only at weekly code reviews.
Now I don't think it's the silver bullet or holy grail but I'll try anything to hasten the development process whie lowering defect count. I don't try to do everything that XP advocates.
Anyways, if there's one thing you should probably get from XP it's an agressive mentality when programming.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
Maybe there is just too much consultant mumbo-jumbo in the XP publications, but the technique sounds old. Develop incrementally, have a small group of smart people working together, test and release frequently, etc., ... those things have been used as the guidelines for projects for at least 20 years, if not longer. I think one might argue that GNU Emacs and other GNU software was developed that way. I don't see anything "extreme" about it, and in fact tools support for this kind of programming used to be much better. However, it doesn't always work: you really do need people on the project that are really smart, love what they are doing, and can work together. Self-selected groups in open source development fit that profile much better than a bunch of people thrown together into a project in a company, under stress from release dates and career paths.
The conclusion: If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem. If you managers have any understanding of the software development process, they will probably already have a development model in place that is appropriate for your project(s), customer(s), organization, and budget.
Apply some logic, please:
1) No method is fool proof.
2) Every method has advantages.
3) Every method has disadvantages.
4) Good talent and a reasonable method work.
4) Bad talent or a poor method will not work.
I used some pair programming with some junior programmers to rapidly develop a database interface. We had code reviews and detailed coding standards, including coded examples. All code had to have a testing module that test all aspects of the interface.
It worked well, and the quality of the code was good. We ran a little late, but that was for the programmers to get up to speed with the method. I think the code quality would have been only average if the programmers had been working alone. The bug level using this method quickly dropped to zero before this sub-system was integrated with the front end. I found that refreshing, compared to traditional methods.
I don't think XP will work for prima-donna or insecure people. It is just too exposed for those types. you have to be willing to let other people understand your code and style. You also have to accept they may have some constructive criticism. For example the junior programmers made some darn good suggestion on the example code I had created.
I will continue to dabble in XP as so far it has shown good results.
If it works for you, use it, if not find a method that does work.
Any change will be met with resistance from those who feel threatened by it. If you feel threatened by something try to dig deep and understand it and why you feel threatened. Don't just discount it as a silly sound-bite.