Re: PG: Hackers and Painters

[Scott McKay <address@hidden>]

At 3:38 PM -0700 5/15/03, Steve Dekorte wrote:
>On Thursday, May 15, 2003, at 05:17 AM, Zooko wrote:
>>  * Extreme Programming
>>
>>These are three things that some people love and many people hate.  I've
>>noticed that most of the articles (on ll1 as well as many other forums)
>>praising one of these ideas speak from experience.  I tried it, they usually
>>say, and it worked well.  Better than I expected, they often add.
>
>I haven't tried XP personally, but I have noticed that every year or 
>so there seems to be a new "methodology" that is welcomed and 
>promises to deliver where the last one failed. This certainly sells 
>books and magazines and perhaps people(who add the appropriate magic 
>words to their resumes and learn the new "speak"), but the dogmatic 
>adoption of the specifics of each new methodology makes me 
>suspicious.
>
>As an overall pattern, I've noticed that like technology itself, 
>productive ways of organizing work seem to be moving towards ever 
>greater decentralization. (blueprint -> iterative,  large team -> 
>small team, vertical de-integration) Perhaps it would be more 
>productive to follow this trend to it's natural conclusion instead 
>of incrementally removing one false assumption at a time from 
>current paradigms.
>

For the past 20 years or so, I've been lucky enough
to work in small, "agile" teams, doing iterative design,
iterative implementation, etc, etc.  I've done pair-
programming, with mixed success (it seems to depend a
lot on who you choose as your partner).  I've done
unit testing, blah blah blah.  This approach has been
in and out of fashion for a long time, and sometimes
it gets a cool name, like "XP".  I make no claims as
to my contributions to this, I've just been lucky.

In my experience, this produces code that works pretty
damn well, and you get it done pretty quickly.  However,
there are some applications which are very well specified
and whose requirements include zero defects.  It is also
my experience that this methodology we are all talking
about is not as good at doing that, precisely because
even in the face of unit testing, it de-emphasizes the
very compulsive management-heavy processes that help
to guarantee zero-defects.

Sometimes the heavy-weight SEI-style processes really
seem to be the right tool for the job.  I don't think
I would fly on a plane whose controllers were running
XP'ed software.