I am not sure why getting new ideas, often better ideas, is a problem. The way XP addresses scope is to make it clear resources are limited. With the given resources the customers get to choose what they want to pay for. If they want a suite of useless frills that is their business. But in reality customers want important base line functionality first. More often than not it is the programmers who want kool bells and whistles first. Customers are free to put as many frills on cards to be implemented in the future as they like. If they find something even more important than something already in the schedule they are free to swap it. It is up to them, but they are not allowed to just add extra functionality as they please. Scope is completely under control at all times.
While getting the entire programming team involved with the design of every piece of the code might sound good, it results in design by committee, which doesn't tend to work in practice. The best designs come from inspired individuals or from very small teams of people.
Exactly so. That is why Extreme Programming advocates most design is done by two people working together. Only major design decisions are made by more than two people at a time.
individual code ownership minimizes the need for communication across the entire group
Which is why it should be avoided. When no one on the team is communicating and working together the resultant system will be an incoherent mess.
this technique is almost certain to fail for any group larger than a half dozen or so.
As the book states, it is only good in small groups. It has been used with 10 developers successfully. Remember that sometimes a small group working well can produce more than an army working at cross-purposes can.
new team members...
Please read the book first. But since you asked pair programming brings new team members up to speed. The system is shown and explained to new team members piece by piece, line by line.
The problem with debugging is that it tends to take up a huge amount of the project time, and XP seems to want to add even more debugging to the mix (through the use of automated debugging tools).
no, No, NO! Read Kent's book. Debugging time is reduced to a fraction of what it would otherwise take. Writing a unit test is not the same as debugging. Every time I write a unit test I save myself some debugging time tomorrow, next week, next month, and even next year. That adds up to significant savings.
design to throw one away...
no, No, NO! Read Kent's book. You always create a prototype called an architectural spike and then throw it away. It is built into the methodology unlike most other methodologies.
XP is the only methodology that I am aware of that does address changing the base architecture of a system running in production.
Most programming projects don't have the latitude to set prices for each feature, or even to pick and choose which features to implement
Surprisingly enough they actually do. But you have talk to your users and/or customers and assume that you don't know more than they do before this becomes apparent.
What we found is that we were better off always working in pairs. It is all too easy to add unused functionality or subtle bugs when coding up iteration 5 because we are bored and we have a false sense of security.
Or think of it this way. Your system is going to be 90% mundane code and 10% interesting. Do you want your sytem to be 90% low quality and 10% bug free?
Studies have already shown that pair programming produces as much code as two people working separately. But the quality is much higher and that saves you time in the long run.
I am not sure what you mean by "hacking mentality". To me it means lacking a disciplined approach to software development. But Extreme Programming is about discipline and quality.
I am not sure what quality engineering practices are missing. He has code reviews, unit tests, functional tests, design reviews, and intense analysis.
In my 22 years of experience I have found that programming is more and more a team sport every year. Yes, there was a time when lone cowboy coders wrote programmers and were not expected to interact with the other cowboys. Those days are gone forever.
To get a reasonable software product to market or into the user's hands takes a team of people working together. And this is not management directed, this is how programmers who have set aside ego to get a product out choose to work.
Consider that all the great Disney movie sound tracks and most broadway musicals were written by two people working together.
When you find yourself describing your team members as "conceited but clueless idiots" it may be time to change the way you work. Instead of working against each other try working together.
A new methodology called Extreme Programming (XP) has been emerging. The idea which is relevent here is to allow customers to make business decisions and technical people make technical decisions. Also of note is the methodologies emphasis on getting developers to work together as a cooperative team. As well as ways to make code more legable without lots of (obsolete) comments. An introduction is provided at ExtremeProgramming.Org
Slashdot Mirror
I am not sure why getting new ideas, often better ideas, is a problem. The way XP addresses scope is to make it clear resources are limited. With the given resources the customers get to choose what they want to pay for. If they want a suite of useless frills that is their business. But in reality customers want important base line functionality first. More often than not it is the programmers who want kool bells and whistles first. Customers are free to put as many frills on cards to be implemented in the future as they like. If they find something even more important than something already in the schedule they are free to swap it. It is up to them, but they are not allowed to just add extra functionality as they please. Scope is completely under control at all times.
XP is the only methodology that I am aware of that does address changing the base architecture of a system running in production.
Surprisingly enough they actually do. But you have talk to your users and/or customers and assume that you don't know more than they do before this becomes apparent.What we found is that we were better off always working in pairs. It is all too easy to add unused functionality or subtle bugs when coding up iteration 5 because we are bored and we have a false sense of security.
Or think of it this way. Your system is going to be 90% mundane code and 10% interesting. Do you want your sytem to be 90% low quality and 10% bug free?
Program in pairs 100% of the time!
Studies have already shown that pair programming produces as much code as two people working separately. But the quality is much higher and that saves you time in the long run.
I am not sure what you mean by "hacking mentality". To me it means lacking a disciplined approach to software development. But Extreme Programming is about discipline and quality.
I am not sure what quality engineering practices are missing. He has code reviews, unit tests, functional tests, design reviews, and intense analysis.
In my 22 years of experience I have found that programming is more and more a team sport every year. Yes, there was a time when lone cowboy coders wrote programmers and were not expected to interact with the other cowboys. Those days are gone forever.
To get a reasonable software product to market or into the user's hands takes a team of people working together. And this is not management directed, this is how programmers who have set aside ego to get a product out choose to work.
Consider that all the great Disney movie sound tracks and most broadway musicals were written by two people working together.
What if instead of "someone hanging over your shoulder" you had a patner every bit as capable as yourself helping you every step of the way?
When you find yourself describing your team members as "conceited but clueless idiots" it may be time to change the way you work. Instead of working against each other try working together.
A new methodology called Extreme Programming (XP) has been emerging. The idea which is relevent here is to allow customers to make business decisions and technical people make technical decisions. Also of note is the methodologies emphasis on getting developers to work together as a cooperative team. As well as ways to make code more legable without lots of (obsolete) comments. An introduction is provided at ExtremeProgramming.Org