XpLite

Last edit December 5, 2003
XpLite is an attempt to describe a subset of XP which could or should be implemented as an intermediate step or steps between traditional HeavyWeight methodologies and full XP.

XpLite is what people are using while they are trying to get the group to adopt ExtremeProgramming. It is a collection of bits and pieces they can put into place first, and this page discusses which bits and pieces they should put into place first. There is a list of pointers to projects that might have been XpLite.

There is some belief that XpLite is bad because the concept diluttes the message of Xp.. This is not that page. That discussion may be found at XpLiteConsideredHarmful. There is some belief that XpLite is bad because the name dilutes the XpName. Discussion about renaming XpLite may be found at XpJr.

There is some argument as to whether or not even the concept of XpLite is a good thing. This is not that page. That discussion may be found at WhyXpLite.

" What we did [on VcapsProject] was to examine what was hurting our project the most and try to fix it. In our case we had oodles of bugs. Many were of the type MessageNotUnderstood. It was clear that automated testing would help that problem. It was irrelevant that testing was one of the cornerstones of XP. " -- DonWells

If you want something light, that isn't yet XP, and that doesn't infringe on the XP name, then look at the CrystalClearMethodology, which is another of the MinimalMethodologies. Just be sure to implement automated regression unit tests as the first inching towards XP.

XpLite might be some BigDesignUpFront + UnitTests + ReFactoring and tighter iterations. That is a stable configuration and it allows people to back out of corners. It is an easier pill to swallow and it is something that XP will have to beat or embrace if it ascends.

My suggestions, based on the ExtremeRules

1. Begin with ExtremeCoding

2. Introduce a mini ExtremeLifeCycle

Instead of BigDesign's "design design design code code code test test test", or Xp's "dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc", XpLite might use "design design dtc dtc dtc dtc dtc dtc dtc test test".

Problems

How to introduce PairProgramming?

What if politics keep the customer from being involved?

How to make the next step?

Even if you are not able to get full PairProgramming instilled, you can make some strides towards more collaborative development. If you don't know how to do something, ask someone else for help. If they will sit down with you, you've accomplished something. Also, every time someone asks you for help, do it, enthusiastically. These are little pieces but they can help migrate a culture. -- MichaelFeathers

If I were going to introduce XpLite, I'd try to focus on getting to the heart of the matter:
  • automated regression unit tests run at the drop of a hat,
  • constant peer peering,
  • very short delivery cycles,
  • people feeling free to refactor.
That last is the feeling I believe you want to foster, the others are mechanisms to permit it. Therefore,
  • absolutely set in place a unit test harness like Junit
  • increase the amount of peer code peering,
  • get short, frequent delivery cycles,
  • start limbering up people on "refactoring is ok" using the other 3.
I hope / believe that YouArentGonnaNeedIt will grow out of the confidence, and PairProgramming won't be so far away, and the others are easier to introduce afterwards. -- AlistairCockburn

Suppose we ask the boss to let us do a SpikeSolution of XP. That is, we request permission to do do full-throttle XP for 6 weeks (two iterations). By then, we will have done something good to the product under development, and we'll have a bunch of happy XP proponents who will leave the company before going back to the old ways. Anyone game to try?

I'm not worried about persuading the boss. I'm worried about persuading the other programmers! I'm probably not doing a good job of selling XP but they don't want to let go of the SecurityBlanket practices. They hate writing requirements and design documents - they don't do a good job on them, and we generally ignore them once we reach the coding stage, but can I suggest that there's a better way to do it? No......................

I'd recommend 6 1-week iterations. You'll get more practice and have more data. -- KentBeck

Are you trying to convince your peers to use XP on legacy code? I have found that is doubly difficult; code is generally not testable (lots of abstract classes, good layering) unless testability has been built in from the start. Perhaps choosing a new project or sub-system and doing XP on that will help. A clean slate can encourage people to branch out a bit. -- IanRae

See TransitioningToExtremeProgramming, PathDependence

CategoryAdoptingXp