by Asim Jalis
There is a subtle problem with XP. These problems are hard to get
at. Often I know something is wrong, but I can't quite explain
it.
There is a phenomenon, which I have noticed and Ward Cunningham
also mentioned in a conversation, and this is that after a while
XP teams tend to get bored with programming.
There are different explanations for this. Regardless of what
explanation we come up with the phenomenon should be noted. Even
if we cannot explain it, this is something that happens. I have
noticed it on all the teams I have worked on.
One explanation is that people get bored because XP eliminates
the challenge of writing big code. It makes writing bug free code
relatively easy.
Another thought is that XP eliminates hubris. The work that is
done to create a system is so diluted across the team that it is
not possible to look at something and say, I did this. On most XP
teams it is possible to eliminate a member without a significant
loss in team capability. Also the deep consensus that is required
for most decisions, dumbs everything down. Truly innovative and
crazy ideas have almost a zero likelihood of making it into an XP
code base.
Let me give you an example of this last one. Windows has a
component called WMI which is like a giant database that allows
you to change the system programmatically. You can create a
share, change file permissions, read and set system properties,
all from this single database interface.
So we're writing code which contains SQL strings embedded in it.
It would be much neater to write some kind of a code generator
that created C# objects corresponding to the WMI objects, so this
SQL did not need to be written.
The team argues (in a very XP way) that this is YAGNI. We just
need two classes, and these can easily be written by hand. And so
the classes are written. Over time they evolve and have lots of
really specialized logic around them.
Once you go for a specialized solution instead of the general
solution, the special solution evolves and acquires all kinds of
idiosyncracies which make it really hard to refactor it.
Also, the team never really sees the value of the general
solution so it is impossible to sell the big refactoring to them
later.
On an individual project it is much easier to be clever, and then
to bask in the hubris that comes from knowing that the cleverness
has paid off.
This might be one reason why many people who do XP at work do
personal projects at home. The personal projects satisfy that
craving for personal achievement that XP somehow excludes.
Now, there might be XP teams which have avoided this. But somehow
in all the teams I have been in, I have experienced this kind of
boredom with the work over time.
The work gets so dumbed down that it loses it's ability to
engage.
