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.
Extreme FIST fucking, right up your ASS!
More witch doctors and voodoo.
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.
FWIW I'm a 30-year-old generalist and toolsmith, and I honestly don't know whether I'm as sharp as I was at 20. I've certainly seen a lot more design patterns, and IMHO cool ideas that failed for nontechnical reasons. The complexity of the industry seems to be growing explosively, making my drive to know how everything works even more impractical, but that could just be age-based growth of the y axes of all my learning curves.
Don't read books? You want us to think,but not with books?
.. part of accomplishing this is setting up educational resources so they DON'T have to work through the ranks -- mainly because those that do generally become managers -- they don't remain programmers... yet what we need are good programmers.
Certainly, most books are tripe. Some (including XP) aren't -- they're based on well-worn experience.
And speaking for myself, this "working up the ranks" notion is being obliterated by people that have a higher learning capacity than those that *did* work their way up through the ranks.
They do this by a combination of books & practical experience.
Generally I think the #1 industry goal right now is to increase productivity of developers
-Stu
Deja.com and dejanews.com actually used XP.. ... it worked really well
It worked well for them... probably because the code was pretty solid to startout with...
We did have a few instances where DB changes affected code the wrong way... but nonetheless
ChiefArcher
Have your boss buy you a 23" flat screen monitor! Everyone's happy. And if XP doesn't work out, you all have 23" flat screens on each desk. Turn a problem into an opportunity ... to upgrade to better hardware.
But to your point, XP doesn't work in even situation. The problem I see that comes up is that you have unchanging programmer pairs that end up thinking alike.
Just because you're paranoid, doesn't mean they're not after you!
"Also, 2 or more people tend to bicker over editor styles, code quirks (comment format and such) that gets overlooked during a code review"
That's why XP demands strict coding standards. If those issues come up a lot during your coding phase, you're not following XP rules correctly.
Just because you're paranoid, doesn't mean they're not after you!
"It must be created by talented software engineers that understand what the customer's needs are."
:) Anyway, XP programming talks about simple design and short releases. Along with that and following the tools based way that UNIX is built on, we are able to create tools that solve one problem and combining these tools we can solve a big problem or come up with a solution to many problems. Also, the problem about knowing what the user wants is solved with rapid prototyping. I think XP does something similar. Check out Our about page.
I disagree. Here at the ITLAB at MUSC we follow a very similar engineering process to XP. You can check it out on our web site. We also produce quality code with a small amount of people and who are not the most talented programmers. Now we are talented, just not the most.
Can you see Iron City here?
I wouldn't think it'd matter that you have different settings, as long as the actual format of the source produced is the same (if everyone indents differently, it's a PITA). As for the problem with readability, like the other guy says, just use bigger monitors (-; Or for a more pragmatic solution, adjust the font size when you're working with someone who's eyesight isn't as good as yours.
Hey, I'm trying to understand it. (It's working well for me on one project.)
I would consider delivering software on time to be maximizing business value. I also wouldn't be surprised if managers *expected* software to slip release dates and go over budget.
And programmers know this, and pad their estimates. And managers know this, and cut the estimates. Repeat until you get something about as absurd as what exists today in many shops.
On the other hand, you're right about contracts being different in XP shops. My eyes glazed over in that chapter, but I do remember it.
--
how to invest, a novice's guide
I did this:
1
3
5
I also do 4, but in the form of seminars and presentations to the people I work with. Maybe one day I'll get the energy and time to do a book.
I'm not too worried about the cost (see 3) and as I said in my original post, it's nice to be able to show my appreciation to these guys for the benefits they have provided me by sharing their knowledge.
I just find it highly amusing that someone posted that it's better than one big book, when in fact, if you are buying them all, it isn't.
~Cederic
Your listed failures are none of them failures as such. Have you any idea just how many business systems are written, deployed and running fine, using VBA?
XP is not something managers go gooey-eyed over. It's something that in my company the developers have been getting excited about. It is something we can wave at our managers, and at our users. It documents things that we have already been saying, puts them down on paper, takes them a little further and backs them up with case studies, anecdotes and academic research. It means that we can confidently use pair programming on a project, insist on proper unit testing, and write software properly. We can go to users and explain to them the importance of proper user stories (requirements) and how the requirements they give to us will be prioritised, and when they will get results.
Maybe we're a group of like minded developers co-operating closely. Perhaps that is why each technique we try out is proving worthwhile. Or maybe the techniques are actually effective, and anybody with enough integrity to try and do their own job better will gladly adopt them and write better software.
~Cederic
People like you piss me off. Read the book before telling us why you don't like it. I don't like RUP, but I bought the book to find out more about it. I do like DSDM, and I bought the book to find out more. Educate yourself, don't dismiss things out of hand just because they do not fit into your cosy little world.
~Cederic
With all respect, there are many things wrong with your story. Like, what controls were in place on the project team. Why wasn't the IT manager managing the project. Why wasn't the customer constantly flagging up the deficiencies in the regular releases in the software? XP puts controls in place to prevent things like this happening - although I can and will believe that XP is no panacea, I can not believe that you can go 9 months through a project using XP without getting some inkling that things were going horribly wrong. The methodology just doesn't allow such timescales without major warnings occurring.
Also bear in mind that XP is difficult. It's very difficult to get used to (in my experience) and it's very difficult to keep the discipline to follow the process. And if you deviate from the process, some parts of it could easily cause a breakdown.
I do not believe that XP gives a bad name to anybody other than those who say they are using it when they are not using it properly.
~Cederic
Agreed - although I got through the book between 11pm and 1am late one night (and early one morning I guess). Admittedly I've had to re-read half of it since while I'm awake, but it's not a tough book to get through.
~Cederic
It's especially interesting to me that Kent Beck is using something like XP in producing books about XP. Instead of one gargantuan tome, designed to sucker those who buy by weight, Beck is working on a iterative cycle. Release something that solves one problem, get feedback, repeat on a related problem. Here's what Beck has to has to say about this at his C2 wiki web page:
So maybe it wasn't because he had a master plan, but that's ok in the by XP standards. You don't know enough before you start to know where you will end.
XP is a means for people to acheive the excellence *on purpose* that is sometimes acheived by a small group of talented people. Of course it helps if you have a small group of talented people. :-)
[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]
Same here. XP feels like a compilation and pushing to extremes of a bunch of ideas that great programmers were already doing.
Heh, that's what XP is.
There might be some room for wiggling around Pair Programming and the iteration planning process, but if they weren't doing Unit Tests and Refactoring (keeping the tests working), they weren't doing XP. I'm not saying they weren't doing it properly; they were not doing it *at all*.
If they had been doing unit testing, there would not be a situation where they just couldn't get the software to work. THey would have got one piece working, then anohter, then another.
On the other hand, some of the XP practices (pervasive automated unit testing) are extremely helpful for a group working is disjoint, disconnected manner. Rather than argue and ponder whether code works, it is much more effective to have a battery of tests.
Easy. Write a few tests, but don't actually run them as part of an automated process.
If tests depend on someone deciding to test, it is *way* too easy to "fall off the wagon" so to speak.
I think there are some requirements for XP to work:
* the team has to buy in to it. If they don't they are going to be annoyed when people refactor "their" code or write a test their code does not pass.
* The team has to be comprised of people who deeply *want* to build good software.
There are probably more.
To me, that makes doing a lot of automated testing even *more* important.
The authors of XP claim that if you're not using ALL of XP, you're not really using XP. Sure you can mix and match, but it's risky, and it isn't XP by definition.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.
Umm... you realize that XP is not a programming language, right? It's a methodology; a set of rules that a developer team adheres to while working on a software project.
I'm just trying to figure out if you're a troll, or making an honest mistake, or if I read your post wrong.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.
OK, I see. Thats what some of the other replies dealt with, but I wasn't sure if that's really what you meant.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.
XP doesn't claim to work in all cases. Have you read the book?
It's another recipe to add to your cookbook. Use it if you want to.
----
"Oh, bother," said Pooh, as he hid Piglet's mangled corpse.
Also, there's an entire wiki dedicated to Extreme Programming.
--
Unselfish actions pay back better
If you're going to judge the effectiveness of a methodology, you have you include the shops that tried to use it and screwed up horribly, so you can get some idea of your odds of joining them.
(Incidentally, this is a major problem with claims I've seen about the SEI-CMM model (eg. in McConnel's After the Gold Rush). He cites statistics that "prove" CMM is highly effective by only counting shops where it worked. Where it doesn't he says, "well, those shops aren't really using CMM so they don't count." This begs the question, and you can prove anything that way.)
Sounds like you're advocating some XP practices. Which is no suprise since the eXtreme means just take sucessful practices, such as the ones you just listed, and crank 'em up to the max.
You disagree with XP on Planning and Prototyping, I believe. In the XP process, you'd plan to build several sucessively more complete versions of your software. Do high level planning up front, then more detailed planning for each cycle.
Communication, as you say, is the key.
Two brains are better than one. You shouldent be so embarrassed of your code that you cant let another developer look at it. That's a waste of time... Everyone makes mistakes when they're coding... generally the developer you're working with should know you well enough so as not to say "You're missing a close curly" when you know very well you are... If you're working on a large project... Maybe one person has more experience with one aspect of it than another. It's a very easy and fast way to gain coding experience. When we do over-the-shoulder, justification of our methods is simple, because we both respect each other's opinions.
Maybe a conclusion that we could draw from this is that you need dedicated developers working on a project in order for XP to work correctly.
I know how your girlfriend must have felt, being on a team of incompitent programmers... From what I gather, XP is for people who actually want to use the methods discussed, and it's probably not intended for people who dont care how they code, as long as they get their deposit in the bank (IMHO). I usually find when code gets destroyed around here, it's because a lack of communication in the workplace. I can imagine how terrible it would feel to have code destroyed, and then having someone try to incorrectly justify why they did it without consulting you in the first place...
Anyway, that's just my $0.02 CAD, (roughly 0.0132 American).
Aegis seams as the prefect tool to use with XP.
But have anybody used it for XP?
I would like to know !
Knud
Extreme Programming Installed
pricegrabber.com
Extreme Programming Explained
pricegrabber.com
Extreme Programing
pricegrabber.com
Disclamer: I work @ pricegrabber
Christopher McCrory "The guy that keeps the servers running" chrismcc@gmail.com http://www.pricegrabber.com
For what it's worth, I have had only good experiences with group programming. However, I am still in school and all of my group programming experience has come from classes, not from work. I think one of the biggest potential gains from group programming is that it is much easier for a small group of people to think around a problem than a single person. If a single programmer runs into a problem for which he/she can't think of an elegant solution, he/she might decide to just give up or hack around it. However, with more than one person, ideas can be bounced around and it seems more likely that a reasonable solution will appear in less time. Given the extent to which programming is a process of solving lots of small problems, group programming seems like a big advantage to me.
Ben
I have to disagree. I read these books and I read about programmers with similar problems to mine and how they dealt with the problems and learn from their mistakes instead of making the same mistakes on my own. Certainly their particular solutions might not be optimal for my problem area, but at the same time, I can learn from what they did and adapt their solutions for my environment. In 'Extreme Programming Explained' Kent makes it very clear that not all projects should use XP. While I do work on projects that shouldn't use XP in general, I learned a number of techniques and ideas that are useful for my project (some we were already doing, and now I know why they work).
In CS we encourage people to reuse code and read other people's source to improve their own code. Should we not extend this to how we program, not just what we program?
- Mike
"I don't think it's selfish, to eat defenseless shellfish." -NOFX
refactoring, in a group of people that don't understand how to do it well, can be an evil thing indeed. i have found that it can take a group years to get the sense of community required to be able to refactor the shared code in a way that is natural and forward moving. the problem? a shared sense of direction. overdesign is not a problem, as some have mentioned ... shared vision is what is needed for group refactoring to happen happily. if a group of people are not focused on what something should (or could) be, then the efforts of refactoring will be pulling the product in *MANY* different directions. non-XP programming wins out in a shop with a lack of focus, as the focus is generated by a select few (often a few select twits) ... where XP, or group enabled development relies of a focus shared by many people, which can be an incredible thing - when it works.
mx
i'd agree that pair programming is a crock. frequent reviews of requirements, specs, design, implementations and aggressive refactoring are much more effective in every situation i have seen (and those i've read about). pair programming seems to result in a quick path to a loss of focus ... which can occur in any shaped development. focus is really one of the keys, along with vision and raw fsking ability (too many lame developers out there).
mx
I reckon something like this might happen in most companies trying to use XP. :)
One of it's preconcepts seems to be that the programmers are good (even *equally* good perhaps).
Though I happen to like the idea behind XP, I'd also like working at a company at which I could trust the code I've written to anyone else... I would never consider *that* where I work!
Regarding the person that destroyed your GF's code while refactoring, I'd like to point out that the book 'Refactoring' by Martin Fowler (Addison Wesley) is a must read. The refactoring techniques proposed are based on making sure that the code keeps working just like it did. It's also necessary to rely heavily on GOOD unit tests. The thing I like about Beck's approach, is that though it tries to shrink the time you spend designing while increasing the time you spend programming, it also tries to do things very methodically, leaving little to chance.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
Maybe not, but it sure can be helped.
It must be created by talented software engineers that understand what the customer's needs are.
Really? What kind of talent should these engineers have? What techniques should they use? How should they determine what the customer's needs are? How often should they interact with customers? How should they go about their tasks?
The "talented engineers" part is a given for XP; the difference is in the methodology. There are many, many ways to go about it, and not all of them are particularly effective.
The management model that is suitable for development of microwave oven firmware is far different than what is appropriate for development of avionics for passenger airplanes.
On what do you base this claim? Most embedded systems people I know would go about the two pretty much the same way. Of course, the functional requirements will be radically different, but the process will be very similar.
Sometimes the customer doesn't have a clue as to what he wants or what software can do. In others, the customer is keenly aware of what can, and should, be done. Some customers want to have very little involvement in the process and others want to be involved on a day-to-day basis.
An excellent point, one addressed at length in XP Explained. Hence short iteration cycles, business-value focused planning sessions, and early deployment.
There are budgets to consider, also. It does not do any good to create the worlds finest inventory management program if you bankrupt your company in the process.
Yes, exactly. A large part of XP is about having a rational software engineering process that can smoothly and accurately reach its targets. XP can help reduce the creeping featuritis that plagues software projects, and prioritizes critical functionality so that if the project does get in trouble, the most important stuff is already done (i.e., the most value is added to the project earliest).
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.
True, but irrelevent. XP Explained suggests that if your manager is clueless, you simply adopt the XP methodology without telling him. You are a professional software programmer, aren't you? Do what you need to do to get the job done right.
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.
This may come as a shock to you, but that's really not the case. We are in the stone age of programming here, and we all want better tools, better techniques, and better results. These books are written by the kinds of engineers you would b0w to if they worked in your company; go read what they have to say and learn from it, then come back and help make it better.
The "Extreme" (yes, I hate the name too) comes from the way these techniques take good ideas and make them occur continuously. Over-the-shoulder coding is an extreme form of code review. Writing tests before you code and being required to pass regression tests before committing is an extreme form of code testing. Etc.
Open source does have the potential for the self-selected goodness you mention, but in practice only a few open source projects are so lucky. (I personally don't think the Linux kernel makes the cut, for example). But companies are self-selecting too; it's up to you to go find a place to work with other people who "get it" the way you do, or to hire them.
That's interesting -- we found pair programming it the most useful part! Several other posters dislike it as well; I wonder what makes the difference.
It may be. This is much the way chips have been designed for many years. While it may not be for everyone, it seems to be the solution to a variety of problems at my own company. This encourages teamwork and that is good.
I do however have some doubts if it can work in "Silly Valley" where it is all egos and not much else. Still they manage to develop chips and that demands teamwork!
Had they been doing XP "by the book", then nobody would have had their own code. Collective ownership is one of the key points of XP.
things never once worked properly
Had they written unit tests for everything that could possibly break, then things would have always worked properly. Test-first, test-everything is another one of the key points of XP.
If you don't do XP properly, then you aren't doing XP, you're doing something XP-like. Successful XP projects prove that XP works. Unsuccessful XP-like projects prove nothing about XP, they only prove something about XP-like projects.
If you don't follow all of its principles than it's not XP and you can't complain about XP not working.
It's like saying your dishwasher doesn't work because you put the dishes in but don't turn it on (who needs to follow every exacting detail?).
Yes, which is why it won't work at many companies, such as places where all-nighters are common, soda cans litter the desks, neon lights abound and programmers sleep on the couches in their offices.
The first book was Extreme Programming Explained. This book is "Installed" because it talks less about what XP is and more about how to do it.
Pair programming is not "someone watching over your shoulder".
It is two people working together on a problem. And incidentally, not working at one person's computer; they work at a computer set up just for pairing. Each person should have his or her own computer in a private location for reading email (and slashdot).
The name is one of its biggest drawbacks because of people's reactions to the word "extreme". In case anyone cares, the name comes from the fact that XP is just a bunch of well-known, tried-and-true programming practices "turned up to 11". (Since we know testing is good, we'll test everything and even write our tests first. Since we know short development cycles are good, we'll have a new cycle every three weeks. Since we know that communication is good, we'll put everyone in the same room.)
Second of all, the only programmer I'll allow to watch over my shoulder is a dead programmer. And the only way I'll watch some other dimwitted slowpoke feebly hunt-n-peck a single line is if I am allowed to threaten that person with a gun.
I think I can speak for all professional programmers who have just breathed a sigh of relief knowing they'll never have to work with you then. Maybe when you grow up a bit you'll understand something about working with other people.
I don't readily admit this. I admit that it is hard to test for thread deadlock and hard to test the top layer of the UI, but if you design your program with a few layers, you can easily test everything but the thin UI layer.
And with Java you can simulate the user clicking on things (there was a recent JDC article about it), which should help with the UI testing.
I would guess the difference is the maturity level of the pair. Having one coder or the other unable to take constructive criticism, complaining about indentation, etc would completely destroy any usefulness this process has.
It is easy to say 'Oh they weren't really doing XP then' but it is hard to see how any project doing even half of the XP practices could develop something 'that never worked once', and did it for long enough for people to quit because of it. At the very least I would have expected the customer to 'can it after the second iteration.
It sounds more like they were using the AEP method.
Its a, sadly, common phenomenon.
AEP
Umm... no.
If and when I ever get around to writing my first SE book, it will be called "Bullpen Environments Considered Harmful." Go to your local bookstore and get yourself a copy of the book Peopleware for a more in-depth explanation, but in my experience, bullpen environments encourage incidental interruptions and prevent your from getting into that "flow" state in which real work gets done.
I've worked in bullpens, bad cubicles, private offices, and good cubicles, and I think I can safely say that offices and "good" (high-walled, quiet) cubicles are the most effective. Just make sure you have sufficient group rooms available, and that the offices/cubes are large enough for two- or three-person impromptu design sessions.
- PROTOTYPE your brains out and show the results to your users/customers. Requirements will change, understanding will increase. You'll all feel better. ITERATE this until everyone is happy!
That I'll buy, but that's actually a tenet of XP.
- Do the initial design as a group - all of you.
Again, I have to disagree. Group design, in my experience, is an exercise in wordsmithing and wastes multiple peoples' time very efficiently. I've found that a more efficient and effective method is to have one or two people create a design straw man, distribute it a few days ahead of time (to allow for digestion), and then meet in your team-sized groups to beat it into a working design.
Ultimately, it's all about humans working together.....
I think we agree on the destination, but not which highway...
> I don't see anything "extreme" about it
The hype, perhaps
Jeroen Nijhof
"...and remember kids: Always recycle... TO THE EXTREME!!!"
Frogs are primitive animals - so the occasional extra toe is not that unusual. But this is very unusual.
As a corrolary, each week you vote a feature off the project...
Recent troubled project:
5 to 6 talented programmers go off and spend 8 months developing a well defined application.
Each programmer works on different components of the system.
Little customer communication occured and the final release didn't integrate at all with the current systems. Half of the the written requirements were not met.
The different components did not even work well together.
Most of the same developers, plus a few new novice ones implement XP. Pair programming improves developer communications and allows the different system components to always be in sync. Also, each developer becomes more competent and code quality skyrockets.
Religious unit testing before checking in proves additions to the system integrate with the rest. Check-in happened daily, so the system was tested multiple times per day by each pair.
Short iterations and daily builds allow the customer to see the system working often and allows them to make changes quickly and easily without bringing down the schedule or costing mucho man hours.
Building just what is needed and refactoring later allows the developers to focus on the business issues at hand and not worry about predicting the future.
At the end of development, 90% of the requirements are done and most of the other 10% have been deamed to be unnecessary.
Further, there are now 8 developers who know the code base inside and out and bug fixing breezes by.
Don't be fooled by the nay-sayers, XP can work. It can also fail miserably, but that's not the fault of the process. Yes, most of the practices in XP are not new. What is new, is that these best practices have been packaged up into a process that developers, business sponsors and management can believe in. In the business world, this carries weight and in my job that's what pays the bills.
By my memory, the book handles risk in two ways: the planning process calls for the people making the business rules to describe in some detail what they want to see, one feature at a time, and rank these by importance. This way, you solve important problems first. To take your example, if integration with an app server is a high priority, then it tends to get done first, and if it's a big nightmare, you find out sooner. If it's not relatively important, then its difficulty is not a big of a problem.
The second way I remember risk being addressed is that after the business folks set down their stories, the development people evaluate how long they think each feature will take and how comfortable they are with their estimate. If you as a developer see "integrate with app server so that..." written on a card, it's up to you to say, "Whoa, that could be a nightmare." and go from there.
One other thing I forgot. The short iteration, with another planning process each time, means that in a four-month project, the team will have at least three or four chances to realize the app server integration is a monster, instead of having ot catch it at the beginning in the all-determining "requirements phase".
Finally, yes, I think you should read the book. XP isn't a silver bullet, of course, but I see development as a battle against the laziness within human nature. (Like why am I posting to Slashdot right now....) If you find a process that engages you and keeps you working fruitfully, then that's the right one.
mike
Frankly, I'm wary of any design methodology that makes the claims that the XP method does. "Work more efficiently, more openly, get things done better and on time, blah blah blah blah," and worst of all, "works for everybody."
I think that most of the debates over which design method is better or worse or great or terrible are all pretty silly. Despite all of our efforts to define ourselves as a cohesive group of hackers who all have certain traits in common, the fact remains that software developers are all individuals. And as individuals, we all work a little differently.
Do you let other people tell you how to eat your food? Do you expect everyone to eat their food the same way you do? Of course not. The fact of the matter is that XP probably really works great for some people, and horribly fails for others. And the same goes for the traditional methods of programming. I've personally always believed that the waterfall method of development was the biggest load of bull I've ever heard in my life. That doesn't mean that it doesn't work for some people (who definitely aren't me).
What developers and software shops need to think about isn't "what great new method is turning heads and making news?". They should be asking "what software development method, new or old, is best for our team and our group dynamic?".
Books like this one that try to evangelize a certain method with tales of it's success in the wild just kind of piss me off. What they should do is write a set of books for each method that detail the greatest successes and the most horrible failures of each method. Then developers will be able to compare their groups to the winners/losers in the examples and determine which method works best for them and their situation.
XP is to software engineer as management-by-objectives (MBO) is to MBAs - a process du juir.
There is nothing unique in XP that isn't taught in any responsible graduate software engineering program. If their particular twist works for you, then fine. If not, fine. It is the underlying principles of software engineering that matter, not how they are espoused.
K
management doing the priortizing? and agreeing to engineer's schedules without asking sales or contracts first? ludicrous.
I know several programmers at a danish company named Syntax, who use extreme programming, and they are very happy with it.
It often leads to better results simply because the customer needs to be more involved. The problem is, that some customers don't want to get involved. This means that extreme programming won't take over the world.
Oops! My mistake.
best wishes,
Mike.
Tales from behind the Lagom Curtain
Sorry, perhaps I didn't make myself clear enough. I agree that the original poster didn't mention unit tests. My point, however, was the following:
The absence of proper unit testing could be logically inferred from the reports of continual breakage, since proper application of unit tests would imply that this process (of continual breakage) was not allowed to continue.
Formally, (A => not B) => (B => not A), by which I mean, "If A implies not B, then B implies not A".
Apologies for any confusion caused.
BTW, I'm not making any claims about the infallibility of XP here - I'm just nit-picking at logic, really.
Fascinating debate...
--
http://www.gimbo.org.uk/
Not everyone complains about cruft... one of the problems with programming, which XP seems to address, is the assumption that changing existing code will always break things. I'm sure we've all been bitten by it: find someone else's crufty code, spend hours tracing through what it does, attempt to refactor to tidy it up a bit, and much later find that you've broken something because the original code relied on some undocumented side-effect of one of the broken-looking bits of code.
: 'When something is very difficult try doing it more often not less'. That's a mantra everyone ought to chant...
It's not always that bad though - often you can find out what code does, fit a test framework around it to confirm that it does what you think, remove the cruft and check that the tests still run. If the tests are there in the first place (which I reckon is the most important thing in XP), it'll be much easier to refactor the code when needed.
The problem with crufty code is that cruft just accumulates, and gets harder and harder to change. There's an interesting comment on http://extremeprogramming.org/stories/testdb.html
-- Andrem
There has been a major scientific break-in
if a methodology is so fragile that the tiniest deviation leads to failure then that methodology is worthless in the real world.
More than anything else, I think this is why XP will work very well for a few people, and be absolutely reviled in a few years as the worst thing since COBOL.
Don't ask yourself "What would Dilbert do with this ?", ask "What would Dilbert's PHB make of it ?" If something can be bastardised by mindless management cretins, then it will be.
I like the idea of XP, but I'd be very cautious about applying it to a whole office as an edict from on high. Someone in that target group will get it so badly wrong, you'll wish you hadn't started.
I was able to download a 'beta' version of the book a couple of months ago from here . I haven't read it yet, but I have read extreme programming explained which I thought was quite good (although like most people I have no practical experience in this kind of environment, although my current employer is getting close).
With XP being somewhat controversial it was a good topic for me to write a paper about it. The paper was submitted to pass a software engineering course at my college.
In the paper I tried answering where XP is all about, if it's new and if it's useful.
If you have a minute, check it out and I would really be appreciative of receiving comments.
The problem is not whether machines can think, but whether men do
BF Skinner
How can I tell what I think until I see what I say?
-E.M. Forster-
Hmmm, the guy in the "column" seems to have a documentation fixation.
While I write a lot of documentation, I don't read very much of it.
While I find professionally written technical documetation useful, plus anything from 0'Rielly, I am always totally suspisous of anything written at a "project" type level. A typical project just does not have the people, skills or the budget to write good quality documentation.
Time spent trying to make sense of badly written, inaccurate and out of date documentation, is time wasted.
Time spent reading the code is never wasted.
Old COBOL programmers never die. They just code in C.
I think we need to start a new Compassionate Programming movement to go with our new beloved President Bush's Compassionate Conservatism. Principles: * Local control, not management control. Programmers know how to use resources better than managers, so managers should just give them free soda and pizza and get out of the way! * Inclusion. Why should just peoople who know how to program be hired to write software? We should foster a new attitude that anyone can write software, as long as they really want to. Just give them free soda and pizza! * Smaller management. Big management is obviously less efficient than small management. So lets put those managers on diets! Always remeber, you can love you computer, just don't LOVE your computer, if you know what I mean.
- team size up to 10-15 developers
- customer representative available full-time
- pay-per-effort/week instead of fixed-price contract
- correctness requirements on a "business level", not on the "lifes depend on it"-level
Under such circumstances, XP is one of the possible development models you can choose from, offering specific advantages, including:- high efficiency
- high flexibility
- high predictability
It is not the silver bullet - and it does not claim to be. It's just a (good) tool.Stupidity is mis-underestimated.
So far I've had really good experiences with pair programming. No bickering over editors, etc. Just lots of good code produced. I think it's important to choose good partners. IMO, the best pair programming partner is someone who you're well aquainted with and respect (and whose respect you desire), but who isn't a particularly close friend. This makes it far more likely that the 2 of you will remain disciplined and focused on the code. But the key thing to remember is that the goal is to produce working code.
Let's try this again...
Suffice to say that I'm glad I don't work with you. The sort of egocentric, programming-as-heroism you seem to favor is rarely useful on nontrivial problems that require multiple programmers. Usually it's a cover for massive insecurity. If you're confident in the quality of the code you write, you shouldn't have any problem with a partner reviewing it as you write it.
..threaded and GUI programming, which XP programmers readily admit doesn't work well with the XP methodology.
Frankly, I don't see the problem with threads and XP.
Regarding GUI's, you may have some troubles regarding unit testing. But, that is one aspect of XP. You can gain from using it partially. It is not all-or-nothing.
All humans are mortal. Socrates is a human. Socrates is dead.
I'm intrigued. Junior programmers seemed like an excellent target for XP pair programming, especially when coming to grips with a complex business environment.
Also I've been thinking about unit testing in a database context, and I wondered if it had been done successfully before. The problem as I see it is dbs tend to act as global variables. eg. Creating and deleting records and logical sets of records seem to fit the unit testing approach fine, but what about complex processing on large amounts of records? Did you have any exposure to this or advice? Did you reuse unit tests for fundamental objects as you reused the objects at a higher abstraction? (ie, if class c relied on class d, did class cTest call methods in class dTest?)
Anyway, some thought from the coalface would be appreciated ...
I love that this book makes it seem like you can treat all programmers equally. Management is a game of psychology, and while programmers tend to follow certain patterns, they are by no means all alike. Some of us value privacy highly, others don't mind people looking over our shoulders. Some of us have a need to be trusted, others don't mind micro-management. Some of us need to be patted on the back frequently, others take pride in doing their best, others want monetary rewards, others want promotions and responsibilities. Each programmer has different personal goals, and those goals are rarely merely "to work as little as possible," although that's usually part of it. The team will only succeed by making those personal goals coincide with the goals of the team.
This is why I love books like Extreme Programming. It creates colossal failures of a company which my team can then come in and get paid gobs of money to fix.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
It's like Dogbert's matrix of ugly vs. cute crossed with smart vs. stupid. Nobody wants to be paired with a slow stupid partner. But beyond that, the fast and risk-taking coder probably doesn't want to pair with the slow and careful programmer, even though they may both wind up in the same place at the same time.
Premature optimization is the root of all evil
Where I work, we have began implementing extreme programing.
It has a lot of benefits, and even though some stuff seems counterintuitive, it works very well. Designing your tests first, and gettin customers to break down there specification can do wonders to reduce bugs, and speed up development. I was skeptical, but on that level extreme programming works.
It will fail miserably.
heres why:
It will force managers to break down there projects to an incredibly small detail, which means they will have to commit to a direction.It also means the "customer"(manager/dept/whomever) will have to spemnd more time thinking about what they want, instead of give a brief description, and expect it to be done.
It could also lead to sweatshop like working condition where programmers sit down for 8 hour and constently type and change partners, which will lead to burn out.
The Kruger Dunning explains most post on
"the only programmer I'll allow to watch over my shoulder is a dead programmer" It's a brave statemant. sounds to me that you actually have something to hide.
I was going to suggest everyone buy it at Amazon, just to annoy that whole boycott clique, but it turns out thinkgeek actually has it cheaper...oh well, there's always next book review...
--
"...does anyone have experience in a workplace even close to this?"
Yep, I sure do.
My company was a client of a large, ex-international dot.com consulting company that espoused the use of XP. As my company's technical person, I got placed into an XP team.
Lemme tell ya, it was wonderful! These guys ran the project. The project managers stayed out of the programmers' ways, the systems analysts didn't interfere... it was great.
Of course, the product didn't ship, what was done was the worst kind of garbage, it didn't follow the specs that were carefully laid out by the project managers and systems analysts, and they spent nine months on the bloody mess, with a team of (ultimately) 18. (Since then, myself and three others built the entire project in 8 weeks flat. And it actually works!)
It is now the most dire of insults in my dev group to be called an Extreme Programmer, because we've seen what this so-called methodoloy really does:
- It fosters an undisciplined environment where the inmates run the asylum.
- It results in evolved code, which any and every experienced software engineer will tell you is bad, bad, bad.
- It takes much longer than necessary, since the project is evolving constantly.
- The eschewing of documentation means whomever has to inherit the bloody mess is going to be completely lost.
- What code is actually usable is barely of prototype quality.
At the Sun Technology Days here in Seattle a couple of weeks ago, an honest-to-god fist-fight broke out over XP. I can only assume that one of the fellows loved the undisciplined environment wherein no stinkin' non-techie MANAGER was going to tell HIM what to do; the other fellow has probably lived through it.XP is worse than "flavor du jour": it gives a bad name to everyone else in the industry that actually gives a damn about shipping quality software.
Respectfully submitted,
S.
There were plenty of controls in place during the course of the project. The biggest XP problem in this project was that XP requires the customer to be technically proficient in order to successfully manage the project. But the whole point of hiring a consulting firm to build a website is to avoid having to have any technical proficiency at all.
Additionally, the project managers at The Company Who Will Not Be Named were sold a bill of goods about XP and told to make it work.
XP does not work. Like all sweeping generalizations, that statement is, of course, subject to the statistically outlying occasions when the planets align and miraculously something wonderful happens. But I have yet to hear of one major success story using XP besides the C3 project at Chrysler--a company with virtually infinite resources and infinite time to do whatever IT projects they want.
In the real world, XP is as much a red herring as Communism. Good thing it doesn't kill as many people.
S.
Don't give companies any ideas. They may just start throwing programmers off a bridge if you don't get it done in time. The Nightmare continues...
So, in my opinion, XP is a waste of money ;-)
hmm...
rr
Quidquid latine dictum sit, altum videtur.
I think not! Most programs that I am familiar with ignore pair programming, deal with after-the-fact testing, don't discuss refactoring (except perhaps in passing), very much DO NOT emphasize "do the simplest thing that could possibly work". Most academic programs that I've seen push early generalization as a noble design goal, instead of deferring generalization until the point of need (and generalizing by refactoring).
Threads introduce non-deterministic interactions between different parts of a program. This can make adequate testing a pain.
Actually, this means XP testing (with its focus on unit testing) works very well when compared to the traditional "testing" model of code, run, visually-inspect. If you're getting a goofed up result from an operation, and the unit tests for each of its parts pass, you know you've got problem that's a result of the joining of the parts. In this case, the problem inside "joining of the parts" is most likely the concurrency.
If you have a terribly coupled model where the thread-spawning code is mixed in with the code that does real work, then I suppose I can see how it could get difficult to test. However, part of XP's design principles are to do things "Once and Only Once", so this type of code would be frowned upon even if it didn't make testing difficult.
- Dr. Foo Barson
If they can't find a way to make it work with threading, XP has some serious flaws.
Can you clarify that any? I must be missing something, because I cannot fathom how XP has any problems with threading.
GUI unit testing is a trick, but a common point of discussion on XP forums. It's doable in any of several dozen ways. From what I can tell, the only problem is that no one GUI testing practice has emerged as the best.
- Dr. Foo
Duh. If everyone followed your advice, there would be no productivity gains in the world. What do you think makes the economy grow - increased worker productivity. So yes, you should expect yourself to produce better code in less time, project after project.
--
Then it's possible someone wasn't writing thorough enough unit tests, or someone wasn't re-running the unit tests after they refactored. The unit tests are an excellent tool to find out what breaks after you refactor.
I personally would like to see XP adopted in my own company but I doubt it will happen as most of management is very "old school." I am a member of the local XP group that is run by a senior architect that I have worked with in the past, who is very much an advocate of XP and is executing it in his current company. From him, I hear the biggest problem is making management understand it. It seems a lot of companies will buy into it but then they don't really understand it, so they'll leave out some critical issues and focus on things that just aren't true (ie, pair programming means fewer workstations to buy). Our group itself is in the process of running through an XP exercise. We are developing a little open source project following the XP guidelines. It is slow because we are all working in our spare time, and none of us work alone, so we have to schedule time to work with others in pairs. At first I was skeptical about pairs, I had the same reaction as any, but I'm surprised at the value I've gotten out of it. A lot of people think pair programming means having someone watch over your shoulder all day, or telling someone how to write code. This is simply not true, if it is you are doing it wrong. Pair programming, for me, has basically been like continuous code review. I am much less apt and lazy to write crappy code with someone watching me do it, both if that someone is junior or senior ot me because I don't want the junior to pick up my bad habits and I want to look good in front of the senior. The other thing is if you find you are having to tell someone what to write when you are pairing, then you should be the one driving, and the other person watching, but you need to make sure the other person is understanding what you are doing. Having to explain myself like this I have often found holes in my own logic and corrected them on the fly. Also, yes, some people are less skilled than others, that's why you also need to pair senior people with junior people, because they senior people will help the junior people learn, BUT this only works if you keep explaining what you are doing to the junior, and make sure they understand it. For us, the process has been slow going because we only meet like once every two weeks, and then try to get together in pair groups at other times in between meetings, but we've been going at a good pace compared to other projects i've worked on considering the amount of time we've put into it. Another big thing people are resistent to is unit testing. I agree, yes, it's hard to unit test a gui, there are automated tools designed for testing guis, I would suggest using those for testing GUIs. However, it should be easy to unit test the underlying non-gui objects. You need to test them thoroughly too because the whole idea is that when you make changes you re-run the unit tests and see if anything breaks. Two things can happenhere, a test will break, you go fix it, or a test will not break, the code will break, someone did not write a valid unit test. Within the past year I have subscribed to the philosophy of writing the unit test first and I have generated more working code quicker than I ever did before by unit testing. Even if you can't adopt the entire XP methodology, then at least try to adopt unit testing. I failed to convince my management that we should have mandatory unit testing, but I myself am using it and the result is my shit works, and I end up having to wait on others to fix their problems more often than the other way around. I'm not as experienced with the planning aspects of XP, but I am learning. My only comment here is that I very much like the YAGNI principle. It simplifies things greatly, and I see several places in my professional life where we are violating it and it's biting us in the ass. The reason we are violating it is because it was part of the approved design, and things are more difficult becuase of it, and I predict we will rewrite a lot of code for future releases regardless.
The first reply came across as obnoxious and facile, and I'm glad someone said so. I bet a lot of us have been in projects where someone will just come along and uselessly say "You did it all wrong. Read these books and then you will understand. Bye." By contrast, this rblum reply is thoughtfilled and useful.
We have three senior developers; none of us has less than 15 years of experience. Quite frankly, we know what we're doing, so pair programming really doesn't "add" anything.
I do see pair programming as useful in situations where a senior person works with a less experienced developer, assuming the "lead" can teach without being condescending.
I look upon programming as an art, like writing. Good collaborations are rare in writing -- and I don't know of a single painting or statue that was done by two people working together. In my experience, the creative process doesn't lend itself well to multiple independent perspectives...
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
Ah! I forgot to mention: One part of XP that we vigorously ignore is "pair programming." Sorry, it just doesn't work. Good development requires concentration and focus, something you can't get with two people working at the same PC.
And we all know that typing proficiency is inversely proportional to the number of people watching you! ;)
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
You are very skeptical about the value of a book on how to improve processes. If everyone is so clueless, then why won't reading a book on how to do things better helpful? You seem to be saying that either people don't do things right, because they're clueless, and they'll never improve, or they're smart people, so they're already doing it right. What about learning and progression?
Donate background CPU time to fight cancer.
The infamous "garage shops" consistently run circles around the established firms that have the money and the time to implement all the latest management-voodo psycho-babble "best practices" processes.
Books like this are enjoyed by non-technical managers, since they encourage the cookbook application of "practices" upon the technical staff, and promise that management can avoid the basic issue of understanding the technical work at hand well enough to contribute.
How many different management-imposed failures need to be experienced before they wise up? Sadly, they never do, as there is a never-ending supply of fresh-faced wannabe managers with little or no understanding of the work that they are supposed to manage.
Shall we list the failures? 4GLs, Booch et al, client-server, "widgets" and other re-use of code, and nearly every attempt by groups larger than a dozen people.
On the success side, we have thousands of public domain packages, all done in "spare time", with minimal management of any sort.
No amount of neatly packaged happytalk can dance around the basic fact that software requires either very close cooperation between like-minded developers, or a facist, single-minded design that is strictly enforced. There IS no middle ground!
Science is the art of infallibility, perpetrated upon non-scientists
You seemed to imply that refactoring "ruined" everyone's code. Then simply put, whatever happening was not refactoring.
One piece of XP that cannot be severed from refactoring is unit testing. So did they do unit testing or not? If so, how was it possible to "ruin" the code with the unit tests in place?
Flat
Have you _read_ the freakin' book? Please do so before dismissing it out of hand. This rant makes no sense if you read the book.
I'd say that *not* developing this way is extreme. It's easy to categorize as extremists the developers who want to design themselves silly before they code anything. Those guys squirm pretty hard when they're getting skewered in a meeting with senior managers who care about the ends and not the means. They sound like idiots when they have nothing to hide behind but an idealized vision of how the project "should" have gone. That's pretty stressful. I would gamble that more milestone dates are missed because of "analysis paralysis" than any other problem - paralysis caused by extreme devotion to some method of design or construction. Getting fired for not delivering is definitely a wrong turn for any developer's career path. Those that understand this deliver early and often. They balance the means of development with the ends required by the business (or users). This is true for open source and internal corporate projects alike.
XP prescribes some interesting techniques, and some seem more useful than others. I think the author recommends that you scale into XP gradually, try the methods incrementally, keep the ones that work for you, and drop the ones that don't.
Like common sense, it seems old and obvious, but it isn't very common. I guess it's the rarity of it that makes it seem extreme.
XP is not about being on time, under budget. XP is about giving the most business value to the customer at any given time. (And about writing [almost] bug-free code. And lots of other stuff..)
In a nutshell, you present 'stories' to your customer every 3 weeks, complete with estimates. Your customer gets to pick stories for the next 3 weeks that he deems most important. You go implement them.
Lather, rinse, repeat.
Since you do it every 3 weeks and adjust your estimate every 3 weeks, your customer always knows what to expect, and when.
But it's not about fixed budgets. (In fact, XP proponents also have proposed a different contract framework to adress this)
Try www.xprogramming.com for more info. (It has a PDF of XP installed, I think)
If you remove practices, you need to replace them with something that fills the void this left. It doesn't lead to failure on deviation if you think about what you're doing. Just leaving out stuff causes a crash.
He could deduce that their unit testing was not properly installed. You said stuff was never working - this is impossible if you have unit tests in place.
Now if that company tried to switch to XP in the middle of a running project, that might have the same result. XP relies on a strong testing framework. If you don't put it in place from the beginning, you _are_ heading for trouble.
But basically, you're just uncovering the fact that the code was bad to begin with.
And, if you switch in the middle of the project, chances are high that somebody believed XP to be a silver bullet. There still is no silver bullet.
XP has a limited scope. (See your XP is no panacea link. You can adopt practices. You can modify XP. Just don't call it XP then.
The problem is XP is a buzzword right now. So many shops claim to do XP. They only implement a few practices, without understanding what they leave out and why. This implies they're going to fail.
Not because they do not use XP correctly - because they do not understand their own development process enough to see the shortcomings.
We like to make fun of marketing people because no matter how much jargon they learn, they don't know what we do. But for anyone who's read The Lord of the Flies, you know that putting people in leadership roles simply because they think they deserve them is a huge mistake. I've seen many media companies die a slow and agonizing death because the charismatic creatives who ran the place did not know their arse from a business-oriented hole in the ground.
long live free beer
So will I see programming on ESPN's X-Games any time soon?
If you haven't tried it, you don't know what you're talking about. Make a list of all the tests that need to run today. Code the first test that will teach you something. Make it run. Refactor until you can't think of anything else to take out. Continue all day. Did you get more done or less done? Do you feel more or less stressed? Does the code kick or suck? One day won't kill you. Try it (even if you have to spend a lot of time refactoring). Report to the gang.
You can sign up for any freakin thing you want. You want to migrate databases until your butt freezes to the chair, have at. Don't do it with nobody kibitzing, that would be stupid, but you can soak yourself as deeply in any truly useful technology as you want. OTOH if you want to be a generalist, why should some PHB be able to tell you, "You can't migrate the database, you're a GUI dweeb." That would be stupid.
If you can get over the scarcity mentality for just a second, imagine this--your pair partner is the perfect audience for your genius. When I have a really great idea, I spend far more time explaining why it's a great idea than I do explaining the idea itself. When I'm pairing, I have a person who understands just what a bitch our problem is, who's frustrated at not finding a sweet solution, and who thus appreciates my genius. Of course, if it's really a stupid idea I only look stupid to one person.
It can be difficult to prove that a refactoring preserves semantics in the face of threading. This makes you want to isolate the parts of your code that could possibly be sensitive to threading as much as possible, which is A Good Thing.
Quality software cannot be forced into existence by policies. It must be created by talented software engineers that understand what the customer's needs are.
I don't think XP promises quality software if you just adhere to its rules. It's not a check-your-brain-at-the-door methodology. If, however, you adhere to a bunch of its principles (in ways that make sense in your organization), you'll make it hard for the really simple stupid stuff to get out the door. Few real companies are staffed with a complete set of the World's Greatest Programmers.
Programmers often need management, and not all managers understand what programmers are like, nor how to manage them. Given clueless management, XP is an easy way to do better than nothing.
If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem.
Naturally there is no quick fix to bad management. However, there is a lot of insight into programming and managing programmers in this book and other XP books. I did, in fact, put this book under my managers' collective noses and it did, in fact, improve their awareness of managing software. XP is very accessible to managers who are not familiar with how software needs to be managed. There is a pretty gentle learning curve to it.
Of course it's not perfect. Of course it doesn't solve everything. Management who have no clue, however, and who make an open-minded attempt at XP will probably find things improving over unmitigated chaos. Once they recognize the value of a methodology, they're free to choose one that's more appropriate.
Paco is an employee of Tovaris, Inc. who speaks his own mind and not theirs.
Software engineers and hardware engineers should be living and working in a mutual existence; however, what I've seen lately suggests otherwise. The software guys always bellow out, "Damnit, get that router running! Can't you do anything right?!?! You'd be nothing without people like me!!!" Meanwhile, the hardware engineer in the server closet mumbles, "Those stupid coders, so what if they can make tabbed widgets out of nothing? I still control their work; one flip of the master breaker and FOOM! All their work destroyed!"
I'd like to see a "computer development village" sprout up, where everyone knows their place and helps at doing what they can to reach the common goal. Enough of this bull-headed, kernel-sabotaging, router-kicking underground war.
Let's get to work!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
On the other hand, I think we should all chip in and send that company a copy of this book, if anyone needs it they do ;)
-C
"Well kids, you tried your best, and you failed. The lesson is, never try." -Homer Simpson
I don't know about the rest of Extreme Programming...but pair programming (part of Extreme Programming) works really really well. Two people sit at one computer. One person concentrates on making the details...and the other sits there an makes the detail guy justify all decisions. You can even do it while driving. Check that part out. I don't know about the other parts of Extreme programming.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
I was relating XP programming to a Java context, which is what I mostly do. I was making a reference to Java threads and how they are very difficult to do unit tests on.
My one tennet is how to develop unit tests for threaded programming. I would imagine that it would be very difficult to write unit tests to fully test threaded code. I think it would be a very useful thing though, threaded programming tends to introduce some subtle errors and units would greatly reduce debugging time. However, I have also talked to other XP programmers that readily admit that threading is a problem in an XP context.
I agree that threading is sometimes overused and lack of asynchronous IO sucks. In JDK 1.4, there will be support for asychronous IO, FINALLY! But, there are certain problems that are best solved using threads. They are rare, but they do occur. FYI, all jsp and servlets are inherently multithreaded, it just that the framework allows you to write a single thread and the framework handles the multithreaded aspects.
Well, it doesn't hurt, but good
code comes from 3 things: 1.) mastery of the implementation tools (C, C++, Perl) etc.) 2.) mastery of the operating environment (U*ix, windoze). 3.) understanding of the problem to be solved (a program to help someone do such-and-such). These methodology systems mainly address number 3. Most of the failed code I see is because of numbers one and two.
It's glib to say "then they weren't doing XP". I would suggest they were doing the easy parts, not the hard parts.
-- Steve van Egmond, b.math
What you're saying sounds a bit like "We tried using perl and the project failed miserably."
But I do agree that most of the benefit from Extreme comes when you have experienced programmers who can work without a safety net.
Frequent unit testing should catch the coding errors, but the project scope will spiral out of control unless there's someone there who knows what's feasible and what isn't, and you need someone who can actually make the code work.
It's a good methodology in the right situations. Pity that it has become "flavor of the month" at some sites. But it sounds like your girlfriend's experience had more to do with it being a badly-staffed, dysfunctional company than with the methodology they adopted.
Get your teeth into a small slice: the cake of liberty
Let me save you all the wasted dollars you might be conned into spending on XP. Every few years some new dumbass social-scientist-cum-geek develops a new way to write systems. They typically fall into 2 groups:
1. The British Bureaucrat with loads of process engineering experience, a clipboard, a stopwatch, and a penchant for 1950's corporate culture. These types gave us Information Engineering and Waterfall Methodology; OR,
2. The faux-Silicon-Valley-geek-hangeron that gave us such tripe as RAD (Rapid Appl'n Development).
So you wonder what a smart-ass like me might know about it all. Having worked on lots of different types of projects using different methodologies, the best advice I have for you is:
- PLAN, PLAN, PLAN. Work with your users and know your requirements (at least as best you can).
- limit your development/project team to a maximum of 6 or 7 people and knock down them cubicle walls! COMMUNICATE PEOPLE! BE A TEAM!
- PROTOTYPE your brains out and show the results to your users/customers. Requirements will change, understanding will increase. You'll all feel better. ITERATE this until everyone is happy!
- Do the initial design as a group - all of you. Decide up front where the critical pieces lie and you all agree that code walkthrus will be mandatory for these pieces.
- Code walkthrus will not be taken personally and will focus on structure, not style. Standards should be checked and observed for just the basic stuff - e.g. naming conventions, etc.
REMEMBER.... 3/4 of the success of any software project is not the methodology or the technology. It's how well the people get along and understand the social rules of engagement. The other 1/4 is in getting the requirements right which, again, all about social interaction between users, developers, etc. Anyone (and I mean ANYONE) who purports to have created a successful methodology can really only offers methods for communicating openly. Ultimately, it's all about humans working together.....
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
I like this second part - I was somewhat sceptical at first and a friend of mine could somehow only focus on testing routines for GUI's and the like; this might provide some good counterargument.
Moz.
see a Text Widget
I probably should have included that caveat. Bad programmers caught early early enough in their career can be taught good coding skills, but you are right about those who are incapable of learning even after years of development experience.
It's a shame, though. I still think that any 'bad' coder identified early enough could become a 'normal' or 'good' programmer with proper guidance. Unfortunately, there isn't a good teacher/mentor system in most companies, much less contracting companies.
Dancin Santa
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.
In a typical project where each team member works individually on some portion of the product, it seems clear that the low-skilled/newbie progammer will have trouble completing or correctly implementing his portion. In the end, someone will have to go back over his code and perhaps rewrite it altogether.
If we accept that a 'good' programmer is 10x more productive than a 'normal' programmer, it may also be accepted that a 'normal' programmer is likely 10x more productive than a 'bad' or 'new' programmer. While I don't claim that these numbers are by any means accurate, I think you catch my meaning, namely "Bad programmers can be eliminated from a project without the project schedule sufferring a whit."
However, I don't think we can assume that all projects are staffed by 'good' developers. Likely, projects are staffed by a mix of 'good', 'normal', and 'bad' programmers. It behooves the team to bring everyone up to at least the 'normal' level of programming skill. The quickest way to accomplish this is not to throw the 'bad' programmers (as they are the only ones who really need to improve significantly) into the deep end of code, but to have a 'good' or even 'above average' programmer mentor them. By teaming a 'good' and 'bad' programmer into a pair, you can create the teacher/apprentice relationship that results in improved skill of the 'bad' programmer.
The 'good' programmer may spend the majority of the time in front of the keyboard doing the 10x of work that is expected from him. He only loses a cycle or two standing behind the 'bad' programmer, watching and advising. Since the 'good' programmer can essentially dictate code to the 'bad' programmer, the actual cycles lost is negligble, in my opinion.
The newbie sees good code, hears good code, and gets to see how 'expert' programmers go about solving problems. This method of development gets everyone on the team up to a level of productivity that benefits everyone: the 'good' programmer gets a notch on the permanent record and more leverage when raises are passed out, the 'normal' programmer gets to work in tandem with another 'normal' programmer increasing the mutual productivity of both, and the 'bad'/'new' programmer gets to learn the ins and outs of the trenches that is difficult to learn in school.
I don't see any one software development methodology as a cure-all, but working in pairs may turn out to be a huge productivity booster.
Dancin Santa
What you're implicitly saying here is that the software engineers should take the time out before coding to talk to the customer and fully understand his needs.
Unfortunately, the customer's needs change over the time of the project - so a mechanism is needed to update the engineers' understanding of the customer's needs.
XP puts this mechanism in place. That's why the subtitle of the first book is "EMBRACE CHANGE".
The interesting thing is that even if you don't know anything about management, you can read about XP and understand the problems it addressed and solutions it proposes. For some reason I find something strange about people saying that we shouldn't bother to think about or discuss management technique, because you either know it or you don't. It's this attitude which has created the current crop of incompetent managers, and unless the future managers can break the habit, we'll be just as incompetent.
"If your managers have any understanding of the software development process," they can still be swamped by change and complexity.
By the way, I love the .sig ;)
I didn't pay for my operating system either
Try working with a DOG in the office.
I didn't pay for my operating system either
People who get personally offended by a methodology deserve rudeness and condescension. You got off lightly by my standards. Regardless of any previous posts you may have made, I was responding to the content of this one.
In any case, all you're rebutting here are my side comments. You seem to have failed to take on board my actual point, which is that clearly this organization was not doing XP and therefore it does not represent a fair case study for XP's applicability.
See, some of us like to add some information and discussion of the point in hand as well as responding to the irrational content of posts.
I didn't pay for my operating system either
OK, I had to respond to this in particular because I just tried to find this previous post to which you allude. You're referring here to a post on another thread. Sorry, friend, but it's not reasonable to expect people to follow everything you write before responding to a specific post. I just took your post at face value. If it didn't represent your views that's nobody's fault but your own.
Re-reading the post I responded to I found you to be obnoxious and smug, and dismissive of XP out-of-hand. I do not therefore feel badly about making the response I made.
But I'm glad that this isn't your real opinion, because that would be really stupid.
I didn't pay for my operating system either
I read his good post on this topic. It was good. The one I was responding to, however, was lousy.
I didn't pay for my operating system either
This sounds reasonable to me. You're the one getting all arsey about this. Apparently when you miscommunicate your opinions it's other people's fault?
I didn't pay for my operating system either
You're right. I didn't click on the link. Boy, do I feel stupid. If I'd known that the link contained opinions which completely disagreed with the opinions you were posting at the time I would have read it to get a more balanced view of your confusion.
I didn't pay for my operating system either
Of course, you can selectively ignore whatever you like.
I didn't pay for my operating system either
Other people misinterpreting your loose prose due to the fact you were more interested in flaming evangelists than in discussing the matter at hand, is not "them lying". Grow up.
I didn't pay for my operating system either
And your argument is merely that I should have read the better post and based my response upon that. This is irrational.
I didn't pay for my operating system either
Your statements seem contradictory to me. If I say so, it is an expression of (and a function of) my point of view. Your point of view may differ. Again, don't take it personally, especially in a case where you can easily fix the problem by clarifying your original statements. But this, it seems, is beneath you.
I tell no lies here. I may be mistaken on points of fact. I may misunderstand you. This is not the same as lying. Every 8-year-old knows that.
Like I say, if you were really as reasonable as you pretend to be, you could have ended this entire argument in an instant - with a rhetoric bomb, as you put it. By simply admitting that your phrasing was unfortunate, and that your rant was just a rant and didn't represent your full opinions.
Instead, you chose to go the route of personal attacks and calling of names. I'm responding merely to this now; the debate about unit test is long passed. So it's a little bizarre for you to start telling me to grow up. Your conceit is astounding. It hits its zenith when you started psychobabbling.
Now, have you any other advice for a long and happy life, or can we stop this nonsense?
I didn't pay for my operating system either
So we as next-generation managers should be fighting this tendency, not promulgating it.
I didn't pay for my operating system either
Don't allow yourself to be annoyed by it. It shouldn't be important to an onlooker. If you are an onlooker, which I doubt.
I didn't pay for my operating system either
Oh, dammit Salamander, I just realized you gave the "pretending to be another person" game away. You said you weren't interested in continuing in another thread.
I didn't pay for my operating system either
You might be personally offended by XP's insistence you do actual tests of your code, and then fix the code when it breaks, but this requirement hardly qualifies XP as "fragile".
So "without knowing anything" except the fact that the software never worked we can indeed determine that they had missed one crucial component of XP ... hell, of any software engineering.
The XP books, incidentally, do not claim that you have to do all of XP for it to be useful, and they don't claim either that XP is good for every project. YMMV.
Let me know when you come up with a better methodology than XP. I'd love to hear it.
I didn't pay for my operating system either
"To the MAX!" is the slogan for the GameStation 252 and 256, not Itchy & Scratchy & Poochie ;)
I didn't pay for my operating system either
Testing and Pairing was a big thing for us, and certain interesting things came out of it:
1) a couple of the developers that were most opposed to pairing turned out to be legends in their own imaginations, and their reluctance was justified when they were exposed to other people
2) those pairing must burn into it. Yes, you have to sit back and sometimes get to know someone, but that is the benefit. It often took a couple of days before developers were comfortable with each other, but all admitted they were way more focussed when paired than alone. I made sure everyone could kick back and take an email/surfing break though - pairing is more tiring - those that paired usually tried to do their best work all the time.
3) We had all developers take a hand in the new coding standards before we started. Hence, there were very few stylistic bickerings or religeous wars about brackets.
4) Judicious pairing benefits the pair very well - a good combination was good OO and C++ in one head and good C and UNIX system development in another. Both parties learnt from each other, and produced a tight library that was bug free and on time
5) Testing up front really helped refine the requirements.
6) Confidence in the shipped code was very high. There were no bugs, and due to using testing to refine the requirements early on, the library was accurate to the spec.
Our initial foray turned out quite well, but we have other problems - a rather major legacy code base that we can't ignore. We're looking at ways of rolling XP into some of the development here. We accept that XP is currently good for green-field work.
Reading this thread, I also noticed that the detractors seldom seemed to have read the book, dismissing it as 'yet another methodology'. :-)
M
I'd be interested to know what the team really did, i.e. what parts of XP they used and did not use. Were there tests for everything to show that the refactorings worked? Did they pair program, especially with the original authors?
Or did they just run rampant and call it XP?
RonJeffries (XPInstalled author)
This is how I develop software. Take the parts that make sense to you. Ignore the rest.
While I agree that one can't conclude that they weren't doing XP without more data, we do have this from the OP: "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." If the OP means that the code didn't work, that would suggest that they weren't doing the XP testing thing. Can't know for sure, but if you don't release code until all the tests run at 100%, things tend to work properly. Regarding coming to a standstill, XP teams work in two- or three-week increments, focused entirely on delivering user functionality. Maybe this team wasn't doing that. I'd sincerely like to know what was going on, because I'd like to know how to improve the XP explanations and process where they need it.
This is how I develop software. Take the parts that make sense to you. Ignore the rest.
Pair Programming rules because: 1) You can bill the customer twice as much for two people doing the same work. 2) You get your own human compiler that catches some of your dumb-ass errors before the compiler does (Oops, you misspelled "String" there spanky). 3) You make a new friend. Pair Programming can suck because: 1) If your partner rips one, it can stop work for both of you until it clears out.
Why didn't her unit tests protect her code?
"if you do it that way, you'll mess up later because ...
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.
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
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.
It can't address that I have my shell and editor settings vastly different than the person(s) with whom I am pair programming.
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.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
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.
pooptruck
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.
Need a Python, C++, Unix, Linux develop
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.
Need a Python, C++, Unix, Linux develop
"Extreme Programmings Wildest Bug Chases!!!"
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!!!
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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).
I think Pair Programming is probably one of the most unique and promising XP ideas. When someone else is watching you type, you must convince them the code works, makes sense, and isn't hacky. The sum of both developers programming and product knowledge makes the combined solution even better. Unfortunately, I doubt many employers would be willing to hire two developers to "do the work of one person". Plus not everyone can deal with the close watch of Pair Programming, though these people are probably not great team players for non-XP shops.
chris
cpeterso
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.
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) 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.
Slashdot - News for Herds. Stuff that Splatters.
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 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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
Agreed. Thank you, rblum.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
This isn't about my GF. I try not to talk about my GF in public because it really annoys my wife. ;-)
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
This is exactly how I learned C while working on an elaborate game. I happened to be writing it with a co-worker. We would lunch together and fight about the details and think about it separately at work.
... and you won't be expecting that". It really introduced me to the programming habits that you foster to prevent later mistakes.
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
I can only point you to:
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).
Cheers,
Slak
Um, I thought XP was all about creating a very lightweight methodology that respects that software "must be created by talented software engineers that understand what the customer's needs are". I mean, that is the whole basis of XP, with customer stories, iterative development, unit testing, etc. What are you complaining about? Anarchy (i.e., no methodology) simply optimizes the worst-case, at the expense of the average and best cases (clueful customers, talented programmers, etc.).
It's 10 PM. Do you know if you're un-American?
Enduring every little typo and thinko (not to mention spending hours at a time with a random coworker) is a totally different beast.
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.
Having tried some of the XP methods, it's my impression that they don't have to be followed precisely, but you do have to be true to the spirit of them. Most of them are valuable on their own, but some methods are dangerous if used wrongly.
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.
"Having an axe to grind" is entirely irrelevant. Their motives (and identity) are their business, and we shouldn't care whether they're praiseworthy. The merit their arguments may have is the only question worthy of public discussion.
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, both sides must adapt to make pair programming work. You learn emacs, they learn vi. (Last week, I was learning emacs myself for jst this reason.) You learn to work without highlighting, they learn to work with it. And the organization should do what they can to make things better; seeing more code at once is very helpful, but some people have better eyes than others. So you buy 22" monitors for the shared workstations.
Doing things in group always requires a little compromise, so people who are unable to deal with that shouldn't be doing XP.
I see no reason to suggest that good unit-testing practices requires any of the other methodologies. And good unit-testing can hardly be considered a bad thing to do.
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.
First, make it work, then make it right, then make it fast, then, make it bloated!
You forgot to mention that unit tests are required to be automated and binary. If you aren't using automatic, binary regression testing, you aren't doing XP, period. Also, they must be test all the functionality currently being implemented and include aat least one additional test for each failure discovered during testing. This is one of the few core, required elements of XP.
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.
I agree, smart people are needed. I also agree that the practice isn't new - even Beck says it isn't.
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).
I can't spell or type, but that doesn't mean I'm unusually stupid.
> This idea that if you're not doing all of XP you can expect failure is offensive enough.
;-)
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.
Tales from behind the Lagom Curtain
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
There has been a major scientific break-in
Don't people working together like this have to be adults, with functional egos, integrated personalities, and a willingness to give-and-take?
You talkin' to me?!?
illegitimii non ingravare
What do they mean by extreme programming installed? If you're looking at it, isn't it already installed? Shouldn't it be explored or something?
I am !amused.
Second of all, the only programmer I'll allow to watch over my shoulder is a dead programmer. And the only way I'll watch some other dimwitted slowpoke feebly hunt-n-peck a single line is if I am allowed to threaten that person with a gun.
Yeah, and I think I saw a Mountain Dew commercial last week with a bunch of scruffy guys hacking Perl and pouring Mountain Dew down their throats. Oh, wait, that's how everyone programs anyway. Never mind.
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.
}#q NO CARRIER
I've been involved in the development of computer software at every level. Without exception, satisfaction with the "success" of the effort depends on communication between these levels. This relationship should be blindingly obvious, but lack of straightforward communication continues to cripple software development. Perhaps good business strategy does not mesh well with good coding strategy, but a good measure of honesty would increase the level of satisfaction with the process, if not its profitability.
Agreed. We have tried a lot of XP. Some has worked, some hasn't. We ditched what didn't work, but maybe it would work just fine for a different team or a different project.
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.
Hey, they're looking for a spot in next year's X-Games on ESPN. I'm getting ready to thrash some serious code, man. Totally 1337.
What'dya mean there's no BLINK tag!?
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, 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??
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, 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
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, and also check out this column. 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.
"It is a greater offense to steal men's labor, than their clothes"
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
All about me
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.
"...you shouldn't have any problem with a partner reviewing it as you write it."
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
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
"(Since we know testing is good, we'll test everything and even write our tests first. Since we know short development cycles are good, we'll have a new cycle every three weeks. Since we know that communication is good, we'll put everyone in the same room.)"
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
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
My personal motivations, real or imagined, are completely irrelevent to the debate. In fact, the link you provided has a perfect analogy to this situation. In that, a priest's anti-abortion arguments are dismissed out of hand because of his religious beliefs. When you attack a person's motivation for making an argument rather than the substance of his argument, it is an ad hominem attack.
You could make this whole debate thing more challenging by not providing links that disprove your arguments.
You do not understand the purpose of public debate. It is not to convince your opponent that he is wrong. It is to convince the observers that your opponent is wrong. Ad hominem attacks sway only weak-minded people.
But I have pretty much given up arguing with crazy people
And that, class, was an ad hominem attack.
That's what is called an "ad hominem" attack and I have better things to do than get involved in something that is already turning far too personal.
Thank you for responding to my original post and have a good day.
The problem with books like these is that I cannot tell at whom they are aimed. Someone who is an experienced software manager is unlikely to need to an all-encompassing book like XP. It is more likely that they will need focused books on individual subjects like configuration management, needs analysis, and so forth. Nor are they written for the neophyte software manager as they contain far too much for a novice to digest.
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.
My reasoning is that people need to read books appropriate to their experience and responsibilities.
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.
I agree. What I have found be be fairly useless in my reading are books that attempt to reinvent entire software development methodologies rather than hone skills in focused areas.
Peace.
On what do you base this claim?
21 years of professional, successful embedded systems development and project management experience. On what do you base your claim that I am wrong?
Most embedded systems people I know would go about the two pretty much the same way. Of course, the functional requirements will be radically different, but the process will be very similar.
Please warn me if you ever get involved in avionics or any other form of embedded systems development where the safety of people is involved. The level of peer review, design review, testing, etc. is orders of magnitude different when working with embedded systems that can affect the people's safety. Tools that you might trust for developing a programmable home thermostat would never pass muster for a heart monitor.
XP Explained suggests that if your manager is clueless, you simply adopt the XP methodology without telling him. You are a professional software programmer, aren't you? Do what you need to do to get the job done right.
So, without the approval of management, everyone in the software group should start arranging meetings with the customer to discuss requirements and implementation? This isn't Oz. The software methodology is normally set from above. Besides, I am not about to go out on a limb to implement a utopian methodology that I do not believe in.
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.
This may come as a shock to you, but that's really not the case.
My two decades plus of experience leads me to believe that you are simply wrong. Get some more years of experience under your belt before making blanket statements like that one.
"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.
I may be wrong, but I'm never uncertain.
Two-Fisted Tales of Programming, Served In a Dirty Glass With a Hair In It, (c)opyright 1879
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".
I am for the complete Trantorization of Earth.
We are trying to implement it right now, and for the most part it is going well. It's a lot better than what tried to pass for design here three months ago. The sales team loves to think that we listen to them, and operations have a few good points to make about how things are designed (they're our customers). I still hate having a newbie looking over my shoulder and asking inane questions. The "test before you code" design, IMHO, is probably one of the best aspects of XP. It gives you a problem to solve, not a solution looking for a problem. eXtreme Programming (still think it's a dumb name too) is not for everyone. There is a need for more formal documentation in many organizations than is what is provided here, and XP lends itself to conflict between employees because of the proximity that you need to work with them. Myself, I'll give it a chance.
XP does deliver ...just like 4GL, RAD, even WaterFall, once upon a time did deliver: it's recent and looks modern, so attracts a following of programmers, team leaders, user environments that are more open-minded, ready to talk, ... than average
When (if) it gets mainstream, the magic will just wear off...
One more enduring point in XP though: Smalltalk *is* a better language, not because it's OO, but because it's the most self contained & orthogonal.
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
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.
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.
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.
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.