Re: extreme programming overview

[<puff -at- guild -dot- net>]

Andrew Plato writes:

> I got a chuckle out of this posting.  What the author doesn't
> realize is that a lot of the big information technologies of the
> last 25 years came out of environments like this - barefooted
> programmers hacking code without any structure whatsoever.

     "Big" is ambiguous; a lot of the more successful technologies
came out of small, tight teams that placed a lot of emphasis on doing
the work instead of on formal procedures.  A lot of the sharpest
programmers are offbeat individuals.  A lot of the "big" technologies
(i.e. "Big Iron" stuff, massive waterfall methodology projects with
hundreds of programmers) came out of moribund development
methodologies.
 
> I also got a chuckle out of this:
> 
> > *Simplicity
>
> The idea behind simplicity is to keep the code butt-simple and not
> get carried away trying to be too clever. This goal is to remind
> programmers not go off and try and build something that isn't
> necessary. "Supporting current functionality" is a piece of that
> issue and not the totality of it.
 
> This article really isn't that good. Its a watered down,
> interpretation of XP.  

     The article certainly isn't as good as a real XP article, but then
again, I didn't get the impression it was meant to be.  As a short,
easy introduction to the ideas of extreme programming, it's okay.  It
doesn't get across a lot of the fundamental practices, but then again,
some things you have to experience.

> It also treats XP like a complex, well defined process. Which it
> really isn't.  XP is a set of basic ideals that programmers agree to
> uphold. There is usually very little defined process to XP
> environments.

     I don't know what XP you're talking about, but XP as practiced by
the people who invented it has well-defined processes.  They aren't
laid down in excruciating detail, but then again, that's part of the
point of XP.

     Traditional development methodologies try to prevent change
problems by making sure we know all the answers up front, or by
avoiding change, or by controlling change, or at least by documenting
change (so you know who to blame!). They slow the process down and
impose additional overhead, making the original problem that much
worse. 

     Extreme Programming recognizes that change is inevitable and
beyond our control.  It embraces change by discarding the
high-overhead methodologies on the one hand, and on the other taking
simple, well-defined, accepted practices and technologies that most
experts and experienced programmers and software project managers will
agree are worthwhile, and taking them to extremes.

> "Extreme Programming" aims to capture some of the spirit of the
> "barefooted hackers" giving it buzz-words and processes so those who
> need that kind of thing can feel warm and cozy.

     Pair programming, to take one example, and refactoring, to take
another, and unit testing at the level XP practices, to take yet
another are not typically used in most development projects.  Unless
you've experienced them, it's hard to understand what's different
about them.  

     For example, XP-level unit tests are much like a good revision
control system - it seems like a good idea but not such a big deal.
Then when you've done a fair amount of work with one, and suddenly you
don't have it available, you realize how much easier it made your
life.  

     I still don't entirely grok XP unit testing in practice.  I seem
to do a lot of programming that current unit testing doesn't quite
apply to, like GUI development (AWT/Swing) and dealing with browser
interactions in web interfaces.  (I suspect that when somebody invents
a good unit testing tool for GUI development, they'll also along the
way solve the key stumbling block to GUI development.  Once you have a
good language for clearly and concisely expressing what the interface
is *supposed* to do, it's only a small jump to building the actual
interface).

> As for tech docs - if you understand the technologies then it really
> doesn't matter what development methodology is used.

     Tech docs are not dealt with well under XP.  On the one hand, XP
has an ideal the idea that the user docs can be dealt with in a few
pages.  They don't have a lot on how to achieve this, but then again,
most of the XP people aren't writers, they're programmers.  

     On the other hand, XP has an ideal that the internals shouldn't
need docs - if a piece of code needs comments/docs to clarify what
it's doing and how, that's a sign that the code needs to be cleaned
up.  I'm personally somewhere in the middle on this latter question.
I'd like to come up with some javadoc-like approach to composing
system internals overview documents (current javadoc stuff only helps
keep track of APIs and sucks for understanding the relationship
between systems).

Steven J. Owens
puff -at- guild -dot- net


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.