Extreme Programming Installed 259
| Extreme Programming Installed | |
| author | Ron Jeffries, Ann Anderson, Chet Hendrickson |
| pages | 244 |
| publisher | Addison-Wesley |
| rating | 8.75 |
| reviewer | chromatic |
| ISBN | 0-201-70842-6 |
| summary | How to implement Extreme Programming, with strategies,examples, and practical advice. More interesting than it sounds. |
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
Bonus Tracks
- 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.
Review this . . . (Score:1)
Good Grief Another Load of BS (Score:1)
Back in the 80's it was 4GL this and 4GL that.
Then 90's we went through 'Booch is a god' phase.
Now we have a resurrection of XP.
Let me explain what works:
1. Hire developers who think coherently.
2. Let them get on with it.
3. Quit reading books, if you don't know what you're supposed to be doing then you haven't worked your way up through the ranks and should quit developing now.
Re:Quit reading books, eh? (Score:2)
If I were you I'd be extremely careful of how I interpreted that. It could well be that they're asking you questions because the topic falls under your specialty rather than theirs. This occurs on your intellectual turf; that's why people hire consultants. If you went to visit them on their own "home ground" you might have a very different experience. Then it might be you asking lots of questions about what they consider basic knowledge.
Oh, there definitely are people here with a much stronger grasp of the business domain than myself. Or certain technologies. You're quite right that I have to be careful in judging what people know, and usually I assume people with experience are quite competent. What I am bringing up in this conversation is general "nagging thoughts" in the back of my head that come up time and time again when I see wierd gaps in people's knowledge that shouldn't be there given the experience they have.
For instance, I have people that have worked with a particular technology for years, but they have no idea how it works. Very often, people "programmed to an API", and went home. They never leveraged their experience to gain a deeper understanding of what they were using. Perhaps this "coasting" menatlity is lack of talent, or lack of enthusiasm. I don't know.
Of course, there are the 1 out of 5 people that do leverage their experience and deep understanding of what they're using. But it's still sad that it's 1 out of 5 people.
I must disagree. One man's coordination is another man's coercion, and when you're talking about coordinating people's attitudes and feelings that can be far more invasive than merely coordinating their actions. This whole thread has been an example of how strongly many XP proponents insist on adhering to every minor detail and nuance of the XP methodology
I think we'll have to agree to disagree. I don't see XP proponents insisting on adhering to minor details. XP is a very tailorable / customizable process and I don't think any two teams do it the same way, or follow all of the practices.
I also think that my point about "coordinating attitudes & feelings" is less about coersion and more about understanding that most project failures are due to emotions, attitudes, and feelings. Fear, especially.
Most of the time we implement a process out of fear -- the develoeprs fear that we won't make the date, fear that we'll be asked to work overtime -- the customers fear they'll be lied to, or won't be able to make decisions about priorities.
XP says "acknowledge that fear up front", and aim the process towards cooling down those fears.
I've already tried to point out that a methodology which depends on a uniform higher-than-average level of skill/motivation among developers can be considered fragile. By definition, most teams are not composed of such developers.
Of course. It's still open debate whether XP requires higher-than-average developers, but generally I don't believe it does. One of the major goals of XP is to get average developers to work productively, with a senior developer or two coaching & guiding them. It does require developers with relatively high discipline, however, which is a potential fragility factor.
At OOPSLA 2000 in Minneapolis this past October, some of the people that were involved with XP's inception (Beck & Fowler, in particular) feel that XP *will not succeed* in most cases, mainly because of the cultural demands it places on the IT organization and the responsibility it demands of the customer.
The general agreement at this session was that "that's okay", because those that *do* use XP enjoy it, and are arguably turning out quality software with high productivity, and having fun while they do it. And that should be all that matters.
However, with business looking for further ways of improving efficiency, there's bound to be a tidal wave of opportunists looking to sell XP the "next great thing". XP probably isn't it, though it definitely is an extraordinarily effective process under particular circumstances.
Re:Quit reading books, eh? (Score:2)
I agree with you. Older programmers are, generally, very smart.
Young people generally do think they're smarter than they actually are.
Here, however, is my point:
- Speaking as a "young'un" I feel I have lots to learn from older/wiser programmers. Problem is that they're a rarity these days -- most people aren't much older, and certainly not much wiser. Do I say this out of arrogance? No, I say this out of pure observation. The few gurus I've had the pleasure of working with have been the exception, not the rule. Whether you really believe I'm fooling myself on this observation will have to be up to you.
- Most people that "worked through the ranks" aren't really much older, they're actually usually within their late 20's or early 30's. After that they move into management. And I don't believe that it's an industry trend to recognize this is a bad thing. Developers know, but management generally doesn't know (you hear it on Slashdot a lot, for instence). The reason programmers move on to management is because arguably, good managers are in *shorter* supply than good programmers. So management promotes whoever shows potential. At least, from my observation.
Now, a bit of an explanation of my position: I mentor and train people in C++ and Java, OO design, and transactional systems design, and I also help architect financial trading systems (where "architect" for me means "a developer with more influence".. I don't draw fancy bubbles and lines on a paper and call that architecture.)
yet I'm very often 5+ years younger than the people I'm teaching or working with. Usually most people don't believe me when I tell them my age. It *FRUSTRATES* the heck out of me at what I see at my various consulting engagements -- very few older programmers, very few senior programmers or architects, and generally very few people with solid understandings of software engineering, good implementation techniques, or design techniques.
I REALLY should not be the one to teach these people these things, but it's what I do.
- Young people are usually very arrogant & think they know everything. I know I could fall into this trap. That's why I make a habit of staring in the morning every day and saying: "You're young. You don't know shit." , it's also why I devour books, and why I use every scrap of experience I get to my advantage.
But my day-to-day experience seems to tell me that I'm not "crap". I shouldn't know more than people older than me, people with better degrees, etc. but usually they're the ones asking ME for the answers to basic day-to-day questions.
And this is not just about the newest tips & techniques -- this is about day-to-day, how do I code this better, how do I test or debug this better?
- I think in my case, experience has been invaluable to me, but being a voracious reader has helped speed along my progress.
Finally, about XP:
- Everyone has a right to healthy skepticism. I know my history -- I've seen the trends come and gone -- CASE tools, Object-Oriented Operating systems, AI, etc. I've also seen trends come that HAVE made a lasting impact: relational databases, GUIs, PCs, modems, and object orientation.
I've also seen the wave of methodologies that came out in the 90's that killed many forests but didn't help as many projects.
I think the reason I like XP is that it's different. It's the anti-methodology. It's not about ceremony or documentation, it's about coordinating people's attitudes, feelings, and fears into a framework that allows people to create quality software.
One of the frustrations with skeptics is when one paints it as "the same as all the other" failed methodologies, that it completely ignores that this one really *IS* different. Healthy skepticism is good; ignorant skepticism is not.
Some of the critiques from Tom Gilb, Craig Larman, etc, espected industry experts, are definite food for thought. But slashdot arguments that effectively say "don't read books!", or "it's bunk, just hire talented developers!" are just hogwash. If we didn't read books, we couldn't evolve our knowledge much. If we COULD hire talented developers, we wouldn't have a problem would we? While they're lots of skilled developers, there is a dearth of talent.
So how do you maximize what little talent there is? You use a process to align people's strengths and minimize their weaknesses. You explicitly state your fears, you measure your progress constantly, and you continually deliver value at whatever speed you're working at. That's what XP is about.
Of course there are limitations and drawbacks - XP does not have any evidence of scaling over 12 developers -- it's rather new, it requires a highly disciplined team, it needs the guiding hand of a "coach" or "architect", it needs the customer to speak "with one voice", etc.
Generally, when I advocate XP, I explain both sides. Especially in my consulting engagements. And it has worked so far -- I've gotten good results in my pilot attempts at using the process in various international banks that I've worked with.
Re:It worked well for a hobby project. (Score:2)
Although (from memory, I haven't read XP in a while) the supposed way to go is not to be looking ahead to the next problem (that's what refactoring is for), but to concentrate on your one use case and tests. This is one of the parts that didn't sit right with me about XP. I liked the idea of most of it, although as I was reading I was thinking how it might apply to projects I'd been involved in, and wasn't so sure.
Also, since no-one else has mentioned it so far, the main source for information and discussion of XP (and an interesting read in it's own right) is the C2 Wiki [c2.com].
Re:My GF did this (Score:2)
I think the XP books, and "refactoring" make it pretty clear that refactoring without unit testing is really just a form of "cowboy coding", it's not really "refactoring" at all.
There are some parts of XP that stand alone (for example, unit testing), and some parts which in isolation compromise quality and need to be tempered by the discipline of unit testing (such as "refactoring")
In conclusion, I'd bet that there are some parts of XP that you could practice and get immediate benefits (like an emphasis on testing), and obviously these should be done first.
Re:reading (Score:2)
Re:Finally an alternative to Giant Computer Books (Score:2)
It also has the side effect that by the time the other two XP books I have on order arrive, I'll have five XP books, and I'll have spent over $150 on them.
The total amount of material covered by the books would fit into one single $50 book. So perhaps I'm feeling a little aggrieved about the approach Kent has chosen, and maybe a little cynical about his reasons why.
Yes, I know, he's only written two of the five, and one of those with Martin Fowler. But maybe what he and the other people advocating XP have done to improve my own skillset worth rewarding by buying their books. I think so.
~Cederic
Re:no luck here (Score:2)
As a simple example, I like vim with syntax highlighting. My boss (who is also one of the programmers) hates it and can't stand to see look like that. I run my monitors at 1280x1024 or higher, depending on what machine I'm using, and most everyone in my office likes 800x600 tops, on a 17" monitor, and so all I hear is "I can't see your code" and stuff like that.
Those are things that standards can certainly enforce, at the expense of my freedom to work how I see fit. But yeah, as far as actual comments, you're supposed to follow standards.
Re:My GF did this (Score:2)
It sounds like they weren't really doing extreme programming then. They may have been following some of the principles of it, and calling it "XP".
Things never worked once? The unit tests should be telling you that. And after refactoring, the unit tests should still pass.
I'd suggest a good reading of _XP Explained_ and possible _XP Installed_, compared and contrasted with the practices at your GFs job, may shed some light on what was actually going on.
Re:Sounds Interesting, but ... (Score:2)
Threading is evil and should be avoided. Sometimes, the evil that is threading is necessary, or the most logical way to accomplish something. Usually it's overused for things (like handling asynchronous behavior (i.e. network/socket communication)) that there are better solutions for.
My biggest complain about Java right now is that it has an I/O model that requires the use of multiple threads to deal with more than one socket at a time, for instance.
Re:Sounds Interesting, but ... (Score:2)
A very central tenent of XP is testing. It's probably the thing that does the most to hold XP together.
Threads introduce non-deterministic interactions between different parts of a program. This can make adequate testing a pain.
Wednesday on FOX.... (Score:2)
LISTEN to Bill Gates tell a customer to upgrade to the next version of MS Office!!!
WATCH as Linus Torvalds and colleagues code around yet another Intel processor bug!!!
SEE Outlook Express proclaiming it's love for its user, and melting mail servers worldwide!!!
--
Tried over-the-shoulder (Score:2)
A co-developer of mine here at the office has the eXtreme Programming book, and we've tried the over-the-shoulder method several times now. It's great, it gives each person a chance to add to the code, and it cuts down on the need for a code-review, but does not eliminate the need. I think it really helps us to not be "in the dark" with each other's code too.
I havent tried doing this with any of the other developers yet, but im sure the results would be just as good. I also believe it took a small chunk out of our overall coding time.
I'm intrested in hearing others have tried any other methods (I'm not very familliar(?sp) with the book myself).
Pair Programming (Score:2)
chris
Re:Methodology of the day (Score:2)
I find that most CS students are particularly ignorant about methodology. They're usually quite naive about such things as working in a team and making realistic plannings and tend to overestimate their own capabilities.
Now pair programming is already practiced in many CS schools and universities anyway. Add some course about testing and let different pairs team up to build something larger and you have an nice XP training course.
Because of the short iterations, it is possible for teachers to keep track of the student rather than having to wait for whatever is thrown over the fence at the end of the semester.
Re: New Age Programming B.S. (Score:2)
Well, I doubt the extra couple years of experience gives you the argument, but I don't want to get into a pissing contest either.
Listen, I'm sorry you've got an axe to grind, but I don't think you're arguing the points. I completely agree with the statements you make in this paragraph, but I still claim the management techniques are very similar; you're arguing about tools and degrees of safety. "Amount" of effort, complience, testing, etc. is different than "style". I have seen XP's style used in everything from embedded avionics (flying in an F-14) to applets; they vary wildly in their actual implementation and goals to meet, as they should. XP is not "sloppy", as you seem to imply; it's a technology of management that can be used in many circumstances, including highly reliable embedded systems.
Anyway, reply to this if you'd like to carry on a serious discussion.
Re:My GF did this (Score:2)
Sigh. More rudeness and condescension for its own sake. If you had looked at any of the other posts I linked to, or at my published writings elsewhere (clue: I wrote this [linuxprogramming.com]) you would know that I am in fact a very strong advocate of testing at all levels, including but not limited to unit testing. I will not allow you to misrepresent my argument as being in any way opposed to unit testing. Someone said "you weren't doing XP" and I said "we don't know that" without any reference at any point to which part of XP was omitted. I wasn't referring at all to unit testing when I spoke of XP's fragility or inapplicability. I was thinking more of XP's admitted limitations as linked from one of my previous posts.
Indeed they do not, but several people here seem to be using just that argument as an excuse for a failure when XP was applied.
Take your strawman and shove it. I don't need to come up with a better methodology. It's not necessary for anybody to come up with a better methodology before we can consider XP's limitations or slashdotters' attempts to ram it down people's throats, but in fact quite a few smart people have managed it (if we define better as "more robust and/or applicable") over the last few decades of software engineering study. Yes, Virginia, there was software engineering before XP. Most elements of XP predate XP itself by decades. Good programming methodologies vary quite a bit, but one thing they have in common is that their authors admit there's no magic bullet. If only people here would believe them.
As I pointed out in a previous post, which you should have read before responding, XP is great but it's no panacea. Great things can still be overhyped, and right now - for all its good points - XP is being overhyped. What I seek to do is not debunk XP entirely, but just to bring the expectations down to a realistic level.
Re:My GF did this (Score:2)
What, another post from "NT Christ" full of flame, with not one whit about methodologies? What a surprise! And I expected so much better from you.
FYI, the article may have been originally written for another (related) thread, but was explicitly referenced in this thread, right here [slashdot.org] in the great-grandparent of your own first attempt at flaming. If it's too difficult for you to click on "User #xxx Info" and find it, surely you could look at the head of the thread to which you're responding. No, guess not. Not even that smart, are you? It may have been hard for you to find, but that doesn't make it an obscure reference.
Re:My GF did this (Score:2)
It's bad to lie. It's just plain dumb to lie so obviously. Anyone reading your post is just a click away from its parent, which anyone can see is at least as on-topic and informative as anything you've "contributed". If my reply fell short of my own usual standards for content, it's because I was replying to something that itself lacked substantive content - in particular to your earlier misrepresentation of my opinion. I notice you've dropped that particular theme since it was revealed as mere fabrication.
Do you have anything worthwhile to contribute to this conversation, or is it all like this? I'm usually glad to engage in discussion about programming methodologies, but this...this, I'm tired of after only two or three posts. Even as exercises in flaming for its own sake, your posts are pathetic.
Re:My GF did this (Score:2)
Agreed. Thank you, rblum.
Re:My GF did this (Score:2)
I have never dismissed XP out of hand. In this entire thread, and in the previous thread, I have been quite explicit about that. I believe XP is a good thing, just not as good (not as robust, not as broadly applicable) as some would have us believe. I've said it time and time again, so please stop lying.
Re:My GF did this (Score:2)
If you misunderstand/misrepresent what someone's saying, and then the person disagrees with the distorted version you present, that's not a contradiction. My opinion and my expression of it have remained consistent throughout this thread, and only your understanding of them has changed.
Re:My GF did this (Score:2)
I don't generally accuse people who merely misunderstand my posts of lying. Yet again, evidence of that is abundant, accessible, and contrary to your portrayal. With this and other comments, you in particular have shown a propensity for misrepresentation and strawman construction that is hard to explain as innocent misunderstanding. I call 'em as I see 'em, so if you want me to stop calling you a liar then stop lying. Stop misrepresenting opponents' positions, stop claiming references are obscure when they're right in front of your nose, stop claiming contradictions where there are none, stop claiming that other people aren't addressing the issues when they are, etc. etc. etc.
As ye sow so shall ye reap, and you have some nasty rhetorical habits that fully explain how you have been treated. Fix them and people will start listening to what you have to say. I'm sure you have much of value to say on this and other subjects, but with your current writing style it's just too much of a drag to separate the rare wheat from the abundant chaff. Grow up yourself - and that's meant quite sincerely. You're not doing yourself any favors by acting this way.
Re:Save Some Money Folks (Score:2)
If I may jump in to this little digression...that's a far from prime example. The AC was correct; there was no ad hominem. An ad hominem is an attack against the credentials of a person making an argument. The term does not apply to any arbitrary adverse portrayal of a participant, let alone of third parties. The construction you present - not an accurate paraphrase of the original, but we've come to expect that of you - may be illogical and unconvincing, but it's not an ad hominem. Your use of the term was, simply and bluntly, incorrect.
I don't know whether you believe in "magic bullets" in software, but you certainly seem to think you can find one in this debate. Ain't gonna happen, kid. The only way you're going to get your point across is to take the slow road - stay on topic, stay honest, and convince people by introducing new facts connected with logic. "Rhetoric bombs" such as random insertion of Latin phrases won't do it for you.
Re:Save Some Money Folks (Score:2)
There you go again. You have yourself commented favorably on some of my earlier posts, and yet now you claim that I "seem incapable" of posting anything but meta-argument. How can anyone have faith in the statements of someone who would so casually contradict themselves to insult an opponent?
And technical correctness doesn't matter? You used the term, you should be willing to accept correction on that use. Instead, you rejected the first correction, and have been singularly ungracious in accepting the second. Is that how you react when someone corrects a minor error in your code or your specs? To bring this back on topic, all of the chief XP advocates agree that having the proper attitude is critical to success deploying XP. How can you champion XP by so profligately displaying an attitude that would prevent it from working? That, along with everything else, undermines belief in the sincerity of your enthusiasm for XP. You seem much more enthusiastic about "winning" at all costs than about standing up for any kind of ideal or standard or methodology.
I'm sure we're boring and/or annoying everyone else with this, though. There are better ways and places to discuss the deficiencies in your manner of communication than in a public forum like this. Feel free to send me email - my address is easy to find - because I don't intend to respond to your flamebait here any more.
Re:Save Some Money Folks (Score:2)
I don't see why not. Yes, there's a lot of crap that gets posted here, but I have had very satisfying conversations here. I've made valuable professional contacts with others in my specialty. I've met people who have offered me money to express my views from a better kind of soapbox, I've met people who've offered me jobs, etc. That kind of thing doesn't happen often, but it does happen. Now that I'm less distracted by your flamage, I'm actually working in another window on a more serious post that I hope will rekindle a little bit of thoughtful discussion here. Or maybe not. It's a small investment, really, one that I don't mind making as a form of recreation, and every once in a while it does pay off.
Do you know about despair.com? One of their slogans is The common element in all of your dysfunctional relationships is you. Cute, huh? I believe I also quoted As ye sow, so shall ye reap to you earlier. In all seriousness, I'd like to suggest that if you never have rewarding interactions here like I do, then your attitude that this is "just a place to flame" might be the reason. If you'd do something besides flame once in a while, you might be surprised at the reaction you get.
Re:My GF did this (Score:2)
The AC might have been reading in non-threaded mode and seen the posts juxtaposed despite their being in different subthreads. It might also have been one of the people who follows my posts closely. There seem to be quite a few; sometimes they turn out to be people I know, but more often it's a mystery. Every time I get involved in a discussion a couple of "regulars" seem to pop up - sometimes on the opposite side, invariably well informed wrt my posting history. I guess being a prominent devil's advocate gets some people's attention. OTOH, it might just have been someone who saw a good flame war going on and tracked it for a while before jumping in. There are all sorts of possibilities.
In any case, you can rest assured that I don't need to resort to such trickery. I'm not exactly afraid to express controversial opinions right out in the open, or to flame people - as you have seen. Why would I bother posting as an AC? If you ask me, the idea sounds just a tad paranoid. Relax; I'm not that motivated to "get" you.
Re:Sounds Interesting, but ... (Score:2)
Unfortunately, writing unit tests for programs with asynchronous behavior is likely to be even more difficult than writing unit tests for programs with threads, so the objection re: XP is still valid.
Re:Quit reading books, eh? (Score:2)
Too true, too true. I've been somewhat lucky that way, I guess. Part of it is that I'm a kernel hacker, and the growth in my specialty hasn't been an explosive as in yours. It's a real problem, when such growth occurs, to find enough mentors and examples and even experienced journeymen.
This is very likely to be a cultural difference between your specialty and mine, though I agree that good managers are probably the rarest beasts in the whole software-industry menagerie.
If I were you I'd be extremely careful of how I interpreted that. It could well be that they're asking you questions because the topic falls under your specialty rather than theirs. This occurs on your intellectual turf; that's why people hire consultants. If you went to visit them on their own "home ground" you might have a very different experience. Then it might be you asking lots of questions about what they consider basic knowledge.
I must disagree. One man's coordination is another man's coercion, and when you're talking about coordinating people's attitudes and feelings that can be far more invasive than merely coordinating their actions. This whole thread has been an example of how strongly many XP proponents insist on adhering to every minor detail and nuance of the XP methodology.
Yes. Eventually, skepticism segues into argument by false analogy. Short of that, though, the skeptics' concerns need to be addressed in a forthright manner if one hopes to win them over.
Absolutely, in the case of the former. Mostly, for the latter, because there is a grain of truth to that. Another poster pointed out the dangers of "cherry-picking" your case studies, rejecting any failures from the sample for specious reasons. I've already tried to point out that a methodology which depends on a uniform higher-than-average level of skill/motivation among developers can be considered fragile. By definition, most teams are not composed of such developers.
Exactly. For some teams XP might maximize the talent available. For other teams - I would say most teams - it won't, for reasons I've given elsewhere, and it may even be harmful.
Re:My GF did this (Score:2)
This isn't about my GF. I try not to talk about my GF in public because it really annoys my wife. ;-)
Re:My GF did this (Score:2)
Yes, that is probably true. However, I still worry about the fragility of a methodology that fails to provide benefits - or that actually makes things worse - if it's not followed precisely in every exacting detail (in short, religiously) by highly skilled people. When people are saying that A sucks, and A+B sucks too, and A+B+C sucks, but A+B+C+D will somehow turn out to be really cool, I think it's normal to be just a little bit skeptical. It's like continuing to buy a declining stock because "it has to rebound soon". Most often it's an exercise in denial, not synergy or honest evaluation of results. Maybe this is a false alarm, but don't expect me to adjust the sensitivity on my BS detector because it has served me well at its current setting.
It worked well for a hobby project. (Score:2)
Then we would get together in the evening and code (one watching over the shoulder of the other). I still can't believe how much we accomplished in something like 12 days. And it was a total boon to me, having someone say "if you do it that way, you'll mess up later because
Re:sounds like an old technique (Score:2)
Kaa's Law: In any sufficiently large group of people most are idiots.
Hunter's Corollary: All corporations are, by default, sufficiently large groups of people.
IMO, the problem has never been getting smart people to deliver good code. The real problem is getting the "less than gifted" to produce good (or adequate) code.
It is a rare organization that employs only guru-level employees. What about the remaining organizations? Are they doomed to failure?
To this, I point to Richard Gabriel's well-written essay "Worse is Better" (available at: this location [jwz.org]).
Cheers,
Slak
Re:New Age Programming B.S. (Score:2)
Re:Just say no (Score:2)
Yeah, god forbid that somebody might notice that you're not perfect. And god forbid that you should be confronted with the fact that your colleagues aren't either. Then those errors might get corrected right away, rather than getting incorporated into the final product.
I agree that pair programming takes some getting used to; at first, it feels pretty hard. Eventually, you get used to it. Either way, it produces better code. If you're mainly interested in putting out good work, you'll adjust. And in the meantime, don't forget to take breaks; you don't have to spend 8 hours in a row manacled to somebody.
Yes and no (Score:2)
One of the important elements of XP is indeed continuous unit testing, integrated into the process. Another is continuous customer involvement. A third is short release cycles. All of these drastically improve feedback, which is a vital underpinning to many of the other techniques.
But another vital component is a good team, one where this is mutual respect and a strong sense of shared goals. In the situation above, people were allegedly wrecking one another's code; this either suggests incompetence or internal political struggles that get expressed in the code. Either way, it's a massive management failure to let rogue workers run unchecked.
XP should absolutely not be used in a group of people that is not working as a team. XP is a process that requires people with a sense of community. 90% of the programmers I know have this. 99% of the good programmers I know have this. But if a manager tries to impose XP, she must do it only with people who can play well with others.
Re:He has a point (Score:2)
This is one of those things that is true in theory but false in practice.
Were all participants in a public discussion sane and reasonable people, you might be right. Had I infinite time and infinite patience, you would certainly be right. But none of these things are true.
In practice, if someone does have an axe to grind, they won't be convinced by any rational argument about the topic, as their motivation for continuing the argument has nothing to do with getting at the truth. Try arguing with a PR flack or a lawyer sometime; it is their job to argue a point until the end of time, twisting and dodging to avoid even getting in the vicinity of the truth.
I dunno about you, but I'm mortal. I have a limited amount of time to spend on this planet, and I have stuff to do. I'm glad to discuss thing with people who are, like me, willing to learn and change their viewpoints. But I have pretty much given up arguing with crazy people; I've only got 40 or 50 years left, and I have a lot to do.
In practice, you adapt (Score:2)
Doing things in group always requires a little compromise, so people who are unable to deal with that shouldn't be doing XP.
Re:Yes and no (Score:2)
Re:The good, the bad, and the ugly (Score:2)
I could see how minimalist design without pair-programming and without constant code review might be bad, because these are all essentially checks against errors being made by one programmer. If we are doing pair programming, then maybe code reviews aren't necessary. But, if you decide to do "minimalist/no design", but not pair programming, I can see how that would be trouble. The important thing is to recognize what problem each aspect is meant to solve, and make sure you have a process in place meant to deal with that problem.
Re:My GF did this (Score:2)
If the tests are automated, binary (pass or fail, tertium non datur) and of sufficient scope, it takes real talent to keep a project in a constantly broken state.
Applying Occams Razor, there ain't no belivable way this project was doing proper regression testing.
Re:sounds like an old technique (Score:2)
It is simply naive to think that any group of programmers put together by a company can be made up entirely of talented programmers. All programming methodologies have to deal with this. But XP is likely the best suited to deal with the shortcommings of some programmers in a group through pari programming.
When we did XP, the biggest problem was one guy who didn't like pair programming and none of us bothered to force him (or even try to force him).
Re:damn it (Score:2)
That's cheeper than any (and for many other books too) and significantly less commercial. I mean thinkgeek is just a sad way of targeting people who buy odd things. They browse around and find other people's products (like that PC window kit) and sell it at a markup.
-Daniel
Re:My GF did this (Score:2)
Well, you might not like it, but there it is. Your GF must have known it from the start (they did actually read up on XP first didn't they?), according to Beck in "XP explained" although parts of XP can be used in isolation, it really works properly when you do it all - it is "greater than the sum of the parts" (chapter 23).
Chapter 25 ("When you shouldnt try XP") is also a must read
best wishes,
Mike.
Re:Nothing to see here... Go back to your lives... (Score:2)
Also, XP doesn't claim to be a strict process: it's a bunch of ideas about how you can implement a process. Most of the ideas are ones that seem like common sense when they are explained, but which are ignored by most engineering projects. Draw your own conclusions about whether or not it's a good idea to bundle them together and recommend people try them.
-- Andrem
I am Jack's completely dubious reaction. (Score:2)
You talkin' to me?!?
Care to enlighten me? (Score:2)
Re:Just say no (Score:2)
Do the Dew (Score:2)
Re:Tried over-the-shoulder (Score:2)
My (USD) $0.02 (Score:2)
I'll go out on a limb and say XP can only succeed under the following conditions:
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.)
2. High average team skill level. One of the touted advantages of XP is that its supposed to raise the average skill level of the team. I'll argue the other way: The lowest skilled team member will drag the team and the project down.
3. Well targeted goals. I think this should be a prereq for all projects, but then again I'd like space travel to start for civilians too...
XP is an interesting idea, but lets just focus on the core skills (not just programming, but project too), and not snowboard our way into the trees before we can stand upright.
Thoughts on "successful" coding... (Score:2)
Re:Logic (Score:2)
We're working on a very GUI-intensive project. What didn't work at all was JUnit testing. Their tips on how to write tests for a GUI just don't work. We got Silk Test to do our regression testing, but that doesn't run very often and is a pain in the ass. We've gotten to the point where someone just has to do a daily test by hand to see what's broken, unfortunately.
Selective pair programming, OTOH, is awesome. We don't do it for everything, but for the tougher bits we throw two people on it. We crank out better code in much less time.
Other techniques have worked or not worked to varying extents. It's worth mentioning we have a larger team than the book is probably assuming. It's also worth mentioning that where we've deviated from Extreme without trying it out first, we're usually wrong.
Overall, XP is not a good book because it tells you exactly what to do. It's a good book because it tells you what to TRY, and you keep what works. The process improvements that result from the techniques that work are generally more than worth the time put into trying them out.
Re:Extreme programming? (Score:2)
Re:Attitude (Score:2)
After deciding to back off physical agression for my programming, I channelled my XP agression into non-physical approaches; soon after, one of our directors resigned after "experiencing" a code review I coordinated - he said something about 'the breadth and extent of my profanity offended his religious beliefs in a very deep way'; which is funny, because I'm sure he was agnostic before the meeting... On the other hand, marketing gave me an award for the meeting, calling me "an inspiration for glibness" and thanked me for the (sizeable) additions to their dictionaries.
Things looked good until I made our largest client break down in tears while reviewing case studies over the phone. Meanwhile, the BOFH, [iinet.net.au] the only person with the will and ability to Pair Program with me, is moving on since he feels that my new attitude is infringing on his "turf". They keep "random" drug testing me, under the assumption that my XP energy has an ... illicit chemical component, but I'm clean.
With my XP Energy &tm, my productivity, and thus worth to the company, has skyrocketed; meanwhile, so has my company's liability. Things look tense. Could you recommend my next course of action??
Re:My GF did this (Score:2)
However, pretty much every day, someone stupid would destroy her code under the guise of XP's constant state of refactoring.
Do you mean they broke its design, its style, or its functionality?
If you're referring to the design, then it is possible that your girlfriend is from the "old skool" of OOP -- overdesign everything and make everything conform to a particular arbitrary set of rules.
I don't mean that to sound insulting -- I used to be the same way. My coworkers changing my code was a constant annoyance because they would stomp all over my little flower garden. In retrospect, however, many of the changes that were made were good -- very simple, very clean. I was determined that good code should be uber general.
If you are referring to the coding styles and such -- that means that the team wasn't doing XP, because XP involves a coding standard. When I first saw that having a coding standard was one of the XP practices [extremeprogramming.org], I thought it odd and overly specific. But it is necessary to fit in with the XP practice of "collective ownership" of all code.
If they broke the functionality... well, then why wasn't there a unit test written? The avid unit testing of XP is one of the most visibly enjoyable aspects of the methodology. Traditionally, writing regression tests is a burden.
Beck and others have noticed how much better/faster/more confidently code can be developed if the unit tests are written before the units are implemented. You then implement until all the tests pass, and then you're done.
However, even if you're doing test-first programming like that, breakage will occasionally occur. But when things do break, you have to try to figure out (and write!) a test that could've ensured that the breakage wouldn't have happened. Eventually, (or so I've heard), you learn how to test well enough that you don't have this problem nearly ever.
Remember what ol' Kent Beck says about XP: "80% of the benefit comes from following the last 20% of the practices". In other words, if you are doing nine out of the twelve practices, you're probably only seeing 20% of the benefit. As soon as you plug in those last three is as soon as you'll see the biggest benefit of the methodology.
Of course, my diagnosis could've been completely wrong here -- I'm just taking some guesses.
- Dr. Foo Barson
We need something (Score:2)
I am sure we have all experienced the horror stories of pointy haired managers in the real world. Maybe one of these days, Stephen King will even do a story on it. Those needing examples can inspect this site [rinkworks.com], and also check out this column [byte.com]. Although there are many other examples easy to find around the net.
Sadly, the thing that worries me is that it takes more than a haircut cut to change a pointy haired manager.
The art of managing your managers is an arcane art indeed.
XP works... (Score:2)
That said, XP is not for every programming environment. Layers of management will hinder the iterative process; programmers must be comfortable with "refactoring" their design. We have three developers for our vertical market toolkit, and we can work closely with QA and our customers.
XP assumes that your receive useful feedback from your users and QA. Perhaps our greatest struggle has been to get NEGATIVE feedback from our customers. We bring them down visit, spend a couple days showing them what we have, and what we get are lots of suggestions for additional features, but few comments regarding the overall design and organization of the components. I hope this means we got it right in the first place... :)
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
Re:Tried over-the-shoulder (Score:2)
My programmers have tried it and noticed two phenomena
Many of us multitask when we're working alone. Code a little, read slashdot a little, read email a little, code a little... My programmers find that when they pair program they don't switch to browsing the web or reading email when their partner is sitting there waiting to make progress on their task. It keeps them focused. Since it's active for both participants, however, they don't get fatigued by staying on one task for a long time.
Re:One problem (Score:2)
A lot of management types haven't got a clue when it comes to computers and programming. I've had one virtually freaking out at me because I refused to give an estimate on how long to solve a problem. Ya know, the kind where the 'Where's it going wrong' part could take between minutes and days to find.
Management likes nice, clear deadlines; they also like squeezing as much work out of programmers as possible - and unrealistic deadlines are one such way they do that.
Re:Methodology of the day (Score:2)
Software must compile with no errors before shipping.
All code that causes and error should be fixed before trying to compile again
A compiler must be used to compile the code
Any code which generates incorrect results must be fixed before shipping
All new code introduced into a project must meed these tough compiling guidlines before it's allowed into a shipping product.
Yes, these may seem radical to you but remember, all new methods seem this way at the start. Trust me, use my methods and you will make great code
Yours,
Bob
Re:Just say no (Score:2)
I have no problem with someone viewing my code. But as I write it? Over my literal shoulder? It's hard enough to think with phones ringing, loud conversations outside my cube and tech support questions every 10 minutes--I don't also need someone sitting behind me humming and clipping his nails.
You guys are all on a hair-trigger with the anti-machoism. I wasn't saying I didn't want anyone to see my code--I was saying I don't need company in an already small cubicle.
--
MailOne [openone.com]
Re:Just say no (Score:2)
And since we all know vitamin B is good, we'll take megadoses. Oops, megadoses of B are poisonous, we are now dead. More is not always better.
"Maybe when you grow up a bit you'll understand something about working with other people."
"Working with" other people is no problem. Enduring every little typo and thinko (not to mention spending hours at a time with a random coworker) is a totally different beast.
--
MailOne [openone.com]
Re:Good Grief Another Load of BS (Score:2)
Stroustrup,
Bentley,
etc...
Somebody PLEASE mod that up...
More on topic: It's apparent that some people don't see the value in a formal methodologies. Not that you can blame them; some of the more popular OO methodologies, for example, are too cumbersome for any but the largest companies that can afford to subsidize the related management overhead.
OTOH, it strikes me as sheer laziness to dismiss all methodologies out-of-hand. I'll have to express doubt that the original poster in this thread has worked on a non-trivial project involving more than two coders - it's possible, but it seems unlikely. Even the most coherent thinkers, when working in teams, need to have some guidelines to keep the code readable, the object design coherent, and the work on track toward well-defined business goals.
Of course, that doesn't mean you have to Get Religion and follow Booch or XP or pure structured programming, but it does mean implementing and enforcing things like coding standards, code reviews, estimates, and some measurement of the progress against the goals.
OK,
- B
--
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
One problem (Score:2)
"Wouldn't it be nice if customers, management, and programmers could work together to produce good software on schedule and under budget? "
This implies that you should constantly bring in projects under-budget. You know what happens when you do that? The budget for your next project gets cut. If you manage to come in under budget again, then it gets cut further. Also, management starts thinking that all of your estimates are off, and starts factoring this into their budget decesions. Just let things cost what they cost, for dog's sake! (This is all from actual work experience.) Ok, the anal-retentive rant is over... resume previous discussion.
You want corn? I give you corn.
Re:Extreme programming? (Score:2)
It just depends on the toughness of the words of your era.
I'm surprised they used "Extreme" though. I thought that died the day I saw a children's science sight with at least 30 different topics, each one headed by "Extreme", as in "Extreme Animals", "Extreme Geometry", and "Extreme Lemon Battery".
Good for some situations (Score:2)
XP's placebo effect (Score:2)
no luck here (Score:3)
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.
Re:Quit reading books, eh? (Score:3)
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.
XP works great for us (Score:3)
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".
Extreme programming? (Score:3)
This bugged me, too (Score:3)
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.
Re:My (USD) $0.02 (Score:3)
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.
Re:New Age Programming B.S. (Score:3)
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.
He has a point (Score:3)
Actually, that's not an ad hominem attack. An ad hominem attack [nizkor.org] 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 [slashdot.org] 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.
Re:My GF did this (Score:3)
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.
--
Re:Just say no (Score:3)
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.
Survivor programming (Score:3)
Re:Extreme programming? (Score:3)
LOTS ON WIKI (Score:3)
There is *ALOT* of discussion on Extreme Programming over at wiki...
http://c2.com/cgi/wiki [c2.com]
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...
Seems like a marketting move to me. (Score:3)
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.
Sounds Interesting, but ... (Score:3)
Re:One problem (Score:3)
You want corn? I give you corn.
My GF did this (Score:3)
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.
Re:New Age Programming B.S. (Score:4)
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.
Re:Methodology of the day (Score:4)
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 it (Score:4)
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 [fatbrain.com] or The Software Project Survival Guide [fatbrain.com] 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.
Attitude (Score:4)
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.
sounds like an old technique (Score:4)
Comment removed (Score:4)
Re:My GF did this (Score:5)
What a convenient and obnoxious rationalization. This idea that if you're not doing all of XP you can expect failure is offensive enough. Besides the Inquisitorial insistence on total adherence to every minor tenet of The One True Faith, if a methodology is so fragile that the tiniest deviation leads to failure then that methodology is worthless in the real world.
What's worse than that, though, is the way that, without knowing anything about what this fellow's GF's company did, you reason backward from the fact that they failed to the conclusion that they must not have been doing XP "properly". That's just nauseating.
FYI, we just had a fairly detailed discussion of XP here last week, in the Making Software Suck Less [slashdot.org] thread. Of particular interest might be my XP is no panacea [slashdot.org] post, which contains a lot that would be directly on-topic in this thread (but I prefer linking to copying).
The good, the bad, and the ugly (Score:5)
Logic (Score:5)
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.