AdvantagesOfExtremeProgramming

Last edit February 16, 2005
peter_wise2001 wrote (on the XpMailingList): For an upcoming job interview, I have spent much time today finding out about XP. I recognise that it would seem to solve many of the problems that, in my experience, have beset software development:
  • The dangers of concentration on the abstract at the requirements/design stage of the software development cycle.
  • The necessity of reiteration in the cycle and in parts of the cycle.
  • The loneliness the programmer and the stress caused by code reviews.
  • The difficulty in tracking true progress.
  • Lack of regular customer involvement and the risk of "making the wrong product" for the customer.

The UsualSuspects replied:
  • I'm JustaProgrammer. All I want to do in life is code, eat, have relations, and sleep. Each following BestPractices.
  • Without a team practicing XP, or similar BestPractices, I can't just code.
  • The team enforces worst practices that cause "ProcessWaste", then they enforce other worst practices to clean up.

Observed bottlenecks to productivity:
  • My colleague
    • wrote a class I can't fix
    • delayed integration, causing bugs
  • My team
    • does not run DailyBuilds
    • does not maintain CommonBuildEnvironments
    • does not run my tests every 10 edits
    • treats test failures as bugs I caused by testing too much
    • insists on using languages like VisualBasic that resist flow; by locking up the editor each time you run the TestSuite
    • insists on using languages like PerlLanguage that resist refactoring
    • culture equates "ReFactoring" with "rework" and "adding bugs", despite overwhelming evidence that fewer code lines makes for less bugs and easier upgrades
    • strictly limits my ability to converse with a real "customer", because I might freak them out
  • Code without tests derails my code (with tests), so I must run the debugger I was trying to avoid
  • Other team members (and management) don't agree that running the automated tests is a requirement for checking in the code. So they regularly change the code "away" from the tests, breaking them. And I don't have the time to do "the other half" of their jobs.
  • My boss
    • ordered my colleague not to sit next to me and help
    • ordered me not to check my tests into the house version control system, because "we already have too many modules in it" (mostly CodeForks) [FearOfAddingClasses]
    • tells me my time estimates instead of the other way around
    • refuses to prioritize features in business order, "because you might get the architecture wrong"
  • Our customers refuse to accept frequent releases because they are familiar with vendors using them as their free Quality Control teams

XP is a BulletOfaVeryShinyMaterial, that is known to slay all those lycanthropes.


CategoryExtremeProgramming