Re: XP versus "Charmingly 1970's"

From: Greg Stern <gregdstern_at_verizon_dot_net>
Date: Sun May 30 2004 - 22:55:35 CDT

>
> One of them is an insistance on never backing down. Another is an
> insistance on never doing overall architectural design. In effect,
> pure XP works primarily in the context of straightforward GUI driven
> applications, where you take an overall architecture (event driven
> object oriented GUI framework, for example), and incrementally grow
> your application in that context.
>
> It's much harder to use XP to grow the framework itself, or to use
> XP to develop systems that must conform to complex specs, such as
> voting systems. XP, in its doctrinaire form, lets marketing write
> the development roadmap, deciding which feature to focus on for the
> next step. This is crazy in the world of voting systems.
>

I have to disagree here. I have written software from military applications,
to foundation libraries, to cell phone software to my current job which is
medical devices. I have used a variation of XP in each environment where
members of more traditional software development have been present in each
environment. I'm very used to coming up with a blend of XP depending on the
application and team dynamics.

In my experience, XP doesn't translate to a a lack of architecture. XP
advocates a process of incremental design instead of up front design. XP is
pragmatic; that is you don't over design for parts that you aren't working
on; you design the part you decided are realistic to chew in the current
iteration. There are many advantages of this approach; two good arguments
here is the ability to change focus over time and humility that you can't
think of every way you will want to extend your systems, so you make it easy
to refactor and extend instead.

In my experience, it is crucial to follow a XP similar process for open
source development. Open source development is inherently incremental and
evolving. Attempting to perform a more traditional waterfall model in open
source will at worst fail and at best doesn't take advantage of the ebb and
flow of ideas in which open source shines.

Also, requirements does not have to come from marketing. In my experience,
you define at the beginning of each iteration your goals for that iteration.
In theory, those goals should be set by what the user wants; but they don't
have to. In our case, the user may be the press, election officials, etc. Or
they can be engineer driven, if you have a longer term release strategy. It
depends on the stage the project is. In short, flexibility is good and comes
in to be extremely useful in almost every circumstance I have encountered.

>
>
> But, some key parts of XP transplant very well into other contexts,
> for example, incremental development, where rigorous acceptance tests
> for each development increment are developed in advance of or in
> parallel with that increment.

I think we need to separate requirements and testing from design and
implementation. In certain systems such as medical systems and probably
election systems, it is very important to understand some key requirements
and to define tests that ensure those requirements have been met. So
therefore, I could agree that coming up with a requirements document and
acceptance tests could make sense (though everyone should be clear that it is
an expensive (in time) process). However, I would strongly argue that an XP
design and implementation process is crucial in an open source, evolving
environment.

>
>
> Doug Jones
> jones@cs.uiowa.edu

Greg Stern

==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Mon May 31 23:18:14 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:17 CDT