Re: PG: Hackers and Painters

[Matt Hellige <address@hidden>]

In response to all previous posts in this thread...

I had the wonderful opportunity to work on a 10 to 15-programmer
development team as we grew (literally from nothing) and refined our
process, becoming more and more XP along the way. I was quite
sceptical at first, and as someone with an all-too-large ego who is AT
LEAST as particular and anal as any programmer I've met, I can attest
that 95% of problems with XP are ego-related.

I came to absolutely love pair programming (by which I mean the policy
that ALL production code was to be written with two people in front of
the computer), test-driven development and shared code. It comes at
what seems beforehand like a cost: you must in some cases sacrifice
your personal preferences at the altar of quality code. Looking back,
this process of subjugating my own gigantic ego has been (and
continues to be) enormously beneficial, but I did NOT see it that way
at the beginning.

Probably the most important single factor in the success of this
undertaking is style guidelines. It is absolutely imperative that you
have a coding standard that every programmer agrees to and swears to
follow. This naturally entails compromise and head-butting, but it's
far better to isolate it and get it out of the way at the beginning.
Typically, there will only really be a few big points of contention,
since often what's absolutely essential to one programmer is only
of marginally religious importance to the rest. The guideline we
followed here was that each programmer could write code however they
wanted within the boundaries of the standard, and no one was allowed
to change it. If you felt that this resulted in a divergence of styles
that was too large, you could move to introduce another item to the
standard, and it would be put to a vote. No one (including the CTO)
carried more weight than anyone else. If you weren't confident you
could win the vote, you were better off just letting the two styles
coexist. Believe me, I know very well that this will not agree with
everyone, but as someone who was very unhappy with certain elements of
our standard, I will swear to you that it is worth it, and I've gone
on at length about this because it really is one of the most important
parts of the process.

Here are a few of the benefits that I can personally attest to:
 - every programmer on our team improved, sometimes in areas that they
   were intimidated by or simply disinterested in. This led me to a
   strong belief that engineering process should not protect good code
   from bad programmers: it should make them into good programmers.
 - our code quality was fantastic. With someone to look over your
   shoulder, you're much less likely to write something sloppy or
   cryptic, or to get away with it if you try.
 - once I overcame my initial disgust at compromising on code
   formatting, all the code in the system was formatted exactly how I
   wanted it, no matter who initially wrote it.
 - there was always more than one person who knew how something worked.
   In fact, since pairs were required to switch up frequently (for
   exactly this reaso), there was almost always FAR more than one
   person.
 - everyone had a stake. This is pretty vague and heard to quantify,
   but it made an enormous difference in our design discussions and
   our planning, and especially in process re-evaluation, which we
   spent about an hour on every two weeks. Every one of us saw how
   this process was arrived at and no one felt like it was mandated by
   managers or handed down from the venerable (and unassailable) past.

The mentoring benefit is, in my opinion, at least as important as all
the others combined. We were able to write code at a very high level
of sophistication and expect every member of our team to understand
and maintain it, including those with little or no previous experience.

The upshot of all of this is that I was eormously satisfied with the
results of our effort, and our process was only continuing to improve
when things ended. It was worth sacrificing my personal code
formatting, it was worth sacrificing my complete flex-time schedule
for a "core hours" system, and it was worth spending the extra time
writing all code in pairs and thinking about all this process stuff. I
really would honestly encourage everyone to give it a shot, since at
least for me, that made all the difference.

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net