Xp Questions

At [some given company] we are trying to settle on a methodology: We'd like to use ExtremeProgramming, but expect resistance from the CMM or BigDesignUpFront camps. How can we address questions like the following...

DonWells replies...

Use the PlanningGame. Let the business people decide how many people by dictating when it will be done, however, let the technical people keep it reasonable by dictating what the maximum number of people will be.

This is a symptom of trying to do too much all at one time. Pick one card and SitOnTheOtherCards. Also related to YouArentGonnaNeedIt in that you are obviously getting ahead of yourself.

Do all the code in pairs so that all your code will be equally reliable and understandable.

I have been criticized for saying this: It takes as long as it takes (ExtremeProgrammingChallengeFourteenSplit). During the life of a project an automated test will save you at least 100 times the cost of creating it. Therefore, the harder the test is to write the greater your savings.

However on a more practical note: Usually twice as much to test as to create, about, kinda, sorta, you might say. You include UnitTest time when you estimate how long something will take. Remember that coding goes faster if the tests are written first so that does not mean everything takes 3 times as long. In reality it takes less over the life of the project. Obviously experience is required to be able to create good estimates, so start learning now. Never, ever schedule it separately. It is the second thing to be cut by managers. Code reviews (and PairProgramming) are the first.

You try to deliver something as soon as possible. Use the PlanningGame to determine what the smallest set of functionality that makes good business sense would be. Also keep your customers and users involved in writing UserStories and creating the AcceptanceTests.

XP is designed to work with average people. The team is stronger than the individuals.

RonJeffries is the expert on this. He has written something about using a third party tax package with ChryslerComprehensiveCompensation, but I just can't find it right now. What I remember is we created AcceptanceTests which included ensuring that the tax package gave good results. -- DonWells

One of the advantages of UserStories versus UseCases is that your customer writes the user stories in a language that they actually understand. With a user story you write out what the system is going to do for the customer in business terms. They can then review the stories, add stories, or delete stories. They can tell you which pieces are more valuable. This is different from specifying exactly how the system will interact with itself and the stick figures, er, I mean users. A user story is just enough to allow you to estimate the scope of the task without making a technical or design commitment. Then when you implement the story you talk to the customer and get the details in the context of the system under construction. You discuss what is, or is not possible. You show the customers prototypes. You run the embryonic system with command lines having the customer at your side. With use case analysis the goal is often to completely specify the system up front, guessing at what may or may not work.

With the XP approach your customers tell you what they believe is valuable to include in your system even as the system is being built. This is different from finding out what they would have included if only they had known it was possible.

XP is an ideology that goes against the grain of many established methodologies. Kids right out of school are very idealistic and rebellious. It should actually be a good fit.

Getting PairProgramming started is really really hard. I have been through it twice now. In both cases we started out with pairing made optional in some way. Both times pairing didn't happen. Only when the rule that all code intended for production release must be pair programmed did pairing begin.

One experience that has served me well was when I was a wannabe game designer. I went to seminars and lectures on designing systems of rules that would be fun to use. One very important thing I learned is to keep the rules both simple and concise. If you have exceptions to the rules then you must add more rules to govern the exceptions, and rules for exceptions to the exceptions and on and on. People arguing about what can be programmed individually and what must be paired will suck the fun out of your project real soon. -- DonWells again

Don, Thanks! Ron and Others, more comments?

I do not claim to be an ExtremeProgrammer, but I'd like to pitch in a few comments anyway:

A general rule for adopting a new methodology that promises dramatically improved productivity: Continue using your existing (old) methods to estimate the first few projects. It's likely that the new techniques won't produce as dramatic results as optimists were hoping, and it takes time for the team to learn and adopt the new techniques.

After you're successful with the new techniques, it's time to adjust the project estimating process.

If A depends on B, do B first. (...same as with any other methodology.)

To do ExtremeProgramming, you must be willing to change code that is already working. The "simplest thing that worked last week" may not be good enough to meet this week's requirements, so you'll have to change it. That's OK: Well factored code (RefactorMercilessly) will be easier to maintain than typical systems you've experienced in the past. Try it; see how it works.

Some of your staff is inexperienced: SellPairProgrammingAsTraining. (Yes, it's a lot more than that, but PairProgramming does work very well as a training technique.)

You shouldn't be writing mindless code. In my experience, writing large amounts of "mindless code" is a symptom of inadequate code reuse: Doing CopyAndPasteProgramming is mind-numbingly easy, but it reveals a failure to factor out common code into reusable functions and objects.

As I understand it, IdealProgrammingTime, as estimated by the developer, should include it.

Without XP, when you ask a developer how long it will take to get function X "done," you assume they'll do at least minimal low-level testing, don't you? Thus, without XP, programmer estimates must include UnitTesting, right? XP is no different, except that it makes it harder to get away with cutting the schedule by doing inadequate testing.

XP has a clear advantage here because it has an IncrementalDelivery strategy: Your customer will be able to see a (partly) finished program much sooner in the process. Waterfall approaches can't do this. (...without prototypes and attendant "put the prototype into production" problems.)

Again, SellPairProgrammingAsTraining. It's the best training approach if you have a mix of people of differing skill levels. Everyone learns.

Actually, paring improves skills even if everyone is average: Every person, bringing a different background of experiences to the table, can contribute knowledge that the other person missed. Even experts can learn from novices, because our field is so diverse and deep with technical detail.

Some XP writers on Wiki seem to discourage reuse. This is silly. Reuse is your friend: buy instead of build, when you can.

On any OO project (with or without XP), you should encapsulate 3rd party components with wrapper classes (FacadePattern). If the 3rd party interface is not OO (like ODBC), then you have another good reason to wrap it. If you intend to swap 3rd party tools (even if they claim to conform to a "standard portable interface!") then you have an even more compelling reason to wrap them.

You don't have to write test cases for everything the 3rd party components can do. However, you should be willing to write test cases for critical pieces of functionality that you use, particularly if such features are not well documented and widely accepted in the industry. Buy from reputable vendors. Report bugs to them if you find them. (Otherwise they'll never get it right. ;-)

I hope this helps!

-- JeffGrigg

I myself would not SellPairProgrammingAsTraining. For one thing there will come a day when it is expected that training is over. At that point it will be expected that you break up the pairs, but also you will be expected to produce twice as much. My experience is that you will produce less.

The second thing is that if you pair experienced with inexperienced right out of the starting gate you will set up teacher-student relationships and those are not pairs. PairProgramming has a give and take between equals that can be hard to achieve and accept. The best way to start is to have the experienced people working together and the inexperienced people working together. Try to pair people together that will form an equality relationship. A shy experienced developer could work well with a fresh out. If you have a bully on your project you must watch for disruption of the pairing. Once pairs of equals are established then begin to mix them up. If you have advertised PairProgramming as training you will not be able to pair equals together. -- DonWells

Regarding the answer to

A general rule for adopting a new methodology that promises dramatically improved productivity: Continue using your existing (old) methods to estimate the first few projects.

The thing that makes that difficult is understanding the impact of applying PairProgramming to my estimates. Typically there will be a few domains of expertise on a project (business logic, database, middleware, gui, etc) and the projects will be small in scale so that in many instances I have spec'd 1 individual per domain. (Gui done in html, middleware done in Java, or ASP, or Corba objects, or DCOM, databases done in SQL). I was hoping that the answer would be, "Use twice the people, take half the time" so that I could cost justify PairProgramming on my bids.

-- TonyReno

What evidence exists indicates that PairProgramming takes you faster than Singleton to the same level of quality. So if you estimate the speed of N people, and then use them in pairs, you should go faster. -- RonJeffries

I'm also interested in learning more about ExtremeProgramming. I'm [on a team with questions like those above]. I'm new to ExtremeProgramming, and I'd like a good, quick starting point to learn about it.

-- PaulWarner

Try ExtremeProgrammingRoadmap and http://www.xprogramming.com. Or, for best results, hire one of the XP guys to come teach a course or boot camp. -- RonJeffries

We are 3 months into a good sized project which we have done under XP from the start. The business and developers are fully committed to XP and see the potential. We are trying to go by-the-book with this and really implement XP the way it is in the books and in the XP Immersion class. What we are finding is that as the project gets bigger, some of our problems aren't going away, and others are getting worse. Don't get me wrong here - there are many things that are going very well to include pair-programming, tests, customer involvement, xp process. There are three key things (and probably others) that aren't as smooth as I think they should be.

  1. Our AcceptanceTests are getting harder and harder to reconcile at the end of each story. As the test base gets bigger, there are more and more broken tests each story and they take longer to resolve. Does anybody know if this gets better at some point?

  2. We are using CVS as our code repository because it is built into our IDE, is easy to get going with, and does parallel development. We get nasty collisions fairly often and cause grief and wasted time when people have to chase CVS merge misses around in the code. We can use whatever makes sense, but I don't want to waste even more time experimenting with tools that won't do what we need. Does anyone have recommendations on things like CVS, ClearCase, MKS, that have been best suited for XP projects?
  3. We are using Java and a product called BusinessWare as the building blocks for the project. Java is a robust popular language well-suited for XP, but BusinessWare is a bit more ornery. The BW product doesn't use source code in all of its development; some is done graphically. It is also not really meant to be worked on in a concurrent development mode. Because of our commitment to XP, we have spent much time and energy trying to get BW to a point where we can do concurrent development,do as much as possible in source files, and do UnitTesting inside the product. The stuff we have done has helped a great deal, but the process is not completely reliable since BW isn't perfect for this technique. Last question is, we want to keep this under XP so is there something special we should do with this product to get it to fit better inside or alongside XP?

Sorry for so many questions, but I really appreciate and look forward to hearing any and all thoughts/ideas/experiences people have on this. -- CollNicolson

CategoryExtremeProgramming

EditText of this page (last edited September 22, 2003) or FindPage with title or text search