Thoughtful Reactions To Xp

What we agree with

• RationalUnifiedProcess
  • Many of the primary tenets of the Rational Unified Process are part of XP. We've been using the Unified Process for many years and see the value in most of their recommended practices. We view some the new ideas in XP to be the strong emphasis on pair programming, unit tests, and refactoring.
• PlanningGame
  • Synthesizes viewpoints of business and development.
• PairProgramming
  • Helps improve design/cross train/mentor and results in constant code reviewing.
• UnitTests and RelentlessTesting
  • Uncovers many more defects earlier and improves confidence in system quality.
• RefactorMercilessly
  • Keeps system small and clean and extends its life.
• Exploration/Productionizing
  • Gets system out early and then maintenance releases evolve product.

• UserStory
  • How is a UserStory different from a UseCase - anything new here?
  • How to capture non-functional requirements like performance criteria?
• PairProgramming (For discussion, see ThoughtfulReactionsPairProgramming)
  • How to engage "lone wolves?"
  • There have to be more guidelines for this. Sometimes a module is too small for two people and one person can better handle it. Also, using a fairly thorough design/code review regimen, you can make sure no one gets away with shoddy work. Finally, if you're working on a time-critical piece, sometimes an inexperienced partner slows you down. The concept of pair programming is not universally applicable.
  • During interviews, we are keenly interested in what candidates have personally accomplished. Weak teammates can require lots of hand-holding and their lack of contributions can be hidden by pairing.
• PairProgrammingFacilities
  • Aren't private offices more productive? (see PeoplewareOnSharedSpaces)
• RefactorMercilessly (see ThoughtfulReactionsRefactorMercilessly)
  • Must be controlled otherwise you're constantly refactoring and never adding. No code or design is ever perfect - you have to draw the line somewhere if you have a product to deliver!
• ShortIterations?
  • There is always some overhead for releasing. There is a point (maybe three weeks) beyond which it makes no sense to shorten iterations.
• FortyHourWeek
  • Not very common in our industry!
    • And just because something is uncommon, we're willing to live without it, give up on ever having it and downplay the importance of getting it back? I have never worked for a company or organization that routinely required me to work overtime and I see no reason to start now. Neither does my family.
• Overall
  • We are unconvinced that XP works well for large teams or projects (LargeExtremeProgramming) or even small projects that do not have enough experienced, knowledgeable, and disciplined developers. No methodology will work without the right people
  • Role of metrics is not well-defined - which ones to use and how to gather them?

• Minimal Up Front Design (UFD)
  • Not the most efficient way to write non-trivial software - system will take longer to build without UFD! (See EvolutionaryDesignIsWasteful)
  • Doesn't encourage experience or intuition to play a significant role in design. Design Patterns are all about leveraging others' experience.
  • Precludes synergistic participation of team members in design. (see ThoughtfulReactionsToMinimalDesignUpFront)
  • How to prevent a closed architecture that is not flexible to change when you do minimal UFD? Constantly refactoring the architecture can be very costly.
• TravelLight (TheSourceCodeIsTheDesign)
  • Design documents are very helpful for conceiving and explaining complex pieces.
  • Visual models (UML) are a superior way of communicating non-trivial designs.
  • Are non-coders (managers, analysts, testers) supposed to understand the system by reading code?
• CollectiveCodeOwnership (ThoughtfulResponseCollectiveCodeOwnership)
  • Thrashing can occur by conflicting refactoring efforts. People can get upset with the changes.
  • Without a concept of code ownership, we foresee less motivation for pride in one's work. (Perhaps a complete loss of pride.)
• ContinuousIntegration
  • May be very difficult and time consuming for large, distributed systems.
• UnitTests (For discussion, see ThoughtfulReactionsUnitTests)
  • How to write/automate them for large, distributed, GUI-based systems? (See GuiTesting)
  • We're not convinced that building unit test cases before coding is a good idea. XP discourages design documentation but suggests building executable test cases before coding! Talk about a heavy artifact that needs to be constantly maintained. In most cases, test programs that are written prior to design/code would be obviated by the time the classes are implemented.
• Oral Communications (For discussion, see ThoughtfulReactionsOralCommunications)
  • Does not scale well (either increased number of people or distributed offices).
  • There is much imprecision in pure verbal communication - misunderstandings occur regularly. Imagine relying only on oral communications for architecting bridges, buildings, or airplanes!

with Sagavista R&D team, SAGA Software Inc.: http://www.sagasoftware.com

Fabulous! Thank you so much for the thoughtful response. There is so much here I can't think of how to begin responding, if a response is expected. Let's try starting a page when we discuss one of the "disagree with"s. -- KentBeck

Yes we would like a response. Actually we would like to start a dialog. We are trying to implement some XP practices, but have concerns. -- SuvajitGupta & AliPashaei

Response Links: TravelLight, ThoughtfulReactionsPairProgramming, ThoughtfulReactionsUnitTests, ThoughtfulResponseCollectiveCodeOwnership

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006