[Sussex] Re: Gentoo problems.

[Steve Dobson]

On Tue, Feb 24, 2004 at 06:45:56PM +0000, Geoff Teale wrote:
> On Tue, 2004-02-24 at 17:09 +0000, Steve Dobson wrote:  
> > That is one of the goals of XP.  But XP does not scale.  Medium sized 
> > projects is about the most it can deal with.
> I'm not sure why you feel that way.  

1). I've read it somewhere.

2). Peer programming.  It will break down when the software code base
becomes large enough.  While XP allows codes to be experts in some areas
of the code base it does expect that they will have some knowledge of all
the other areas.

> A more valid point is that it requires incredibly enlightened
> management.  

All project need "enlightened management."

> It's odd how dogmatic people can be about eXtreme Programming, mostly
> these people dismiss it out of hand without practical experience.
<snip>

I've nothing against XP - although I haven't used it myself it is
closest to the way I work on my own.  I still don't think it scales
but that is not a problem - just a limitation.  It also doesn't scale
down to the very small - one coder project :-)
 
> XP is very developer centric to the mind of the average non-developer,
<snip>

Strange - I always thought of it as goal centric.  You make a long term
plan but don't put much effort into because you know that it will change.
You do plan in detail this cycle, next cycle and maybe the cycle afterwards
because they are less likely to change.

> Unfortunately in most cases the hard truths that XP highlights are
> entirely the reason that it doesn't get used.  The customer doesn't like
> to be told that they'll have to work hard to get the software they are
> paying you to develop (of course they're also not prepared to hear that
> information in retrospect).

I agreed, XP does highlight early what is and more importantly is not
going to happen.  If forces everyone to conciser the implications.  Most
managers do not want the "bad" news.
 
> The XP model for development is very close to the "Bazaar" of OSS
> development in large projects except the priorities are defined by a
> given customer rather than by community and personal preference.

Not sure I agree here.  In XP peer program is the key to its success
as every team member know a little about all the parts.  In Bazaar 
programing everyone goes their own way.
 
> In fact many of the core benefits of XP only outweigh their costs when
> you are working on a large project.  Small projects can be much more
> accurately planned and controlled by traditional methods than large
> ones, and the inter-developer communication, pairing, rotation and
> continuous integration (and testing) really start to pay off and
> complexity and timescales increase.

I have a feeling here that we have a different definition of large.  I
once worked on the Nimrod project.  When I join it was 10 years in and 
I don't know how many millions of lines of code had been written, and it
was only half complete.

Even when the code base is only 3 to 5 millions lines of code you can't
get even a basic idea of all of it.  For a start such projects tend you
use different skill sets.  One part is the database, another the GUI for
the front line user, etc.  

In these cases you could do each subsystem as an XP project, and the only
think about the other parts you care about are the interfaces to them.

Steve