[Sussex] Re: Gentoo problems.

[Steve Dobson]

On Tue, Feb 24, 2004 at 08:24:24PM +0000, Geoff Teale wrote:
> Steve Dobson wrote:
> 
> >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.
> > 
> >
> What precludes you from setting up teams of XP programmers specialising 
> in a part of a larger project?  This is common sense.

But that would make it a set of XP projects - which is fine, I see nothing
wronge with doing that way but: Some management system would be needed to
oversee all XP projects.  There is no coding involved here, no programming,
except maybe a little interface design.  So I don't see XP as the
controlling process.

> >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 :-)
> 
> Some aspects of it scale to one person - the way you handle the project 
> planning and customer relations is certainly of benefit to such a project.

And some aspects of Object Orientated Programming scale to assembler.  That
doesn't make assembler an OO language.

I've taken some XP practices and applied them to a small project I was
running.  That doesn't make it an XP project.

For a system to scale *all* aspects must scale.  That maybe a purest view,
but it is one that I hold.

> >>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.
> > 
> >
> That's right, but you see it from a developers point of view (as do I).  
> Non developers often see it as  being developer centric because it 
> expects non-developers to actually do some work as part of the 
> development (I've heard lots of people claim that this is just 
> developers being too lazy to do the work themselves).

Fine - we have slightly different PoVs.  In my experence the more
involvement end users have in the design of the system the better it is
for them.

> >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.
> >
> I think you're putting to much emphasis on that aspect.  Each pair picks 
> one small task to do every and does it and then informs the others of 
> what they have done.  All code is supported by automated tests which 
> allow any pogrammer to make changes in the code and see that it still 
> performs as per spec afterwards (and allows them to fix new bugs arising 
> sooner rather  than later).

That is maybe so, but it is the one part of XP that I haven't seen in 
other programming systems.

> >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.
> <snip>
> 
> Well, our project isn't quite so large, but I don't see why you think 
> that every developer has to know the entire system.  If you have a 
> project so large it's natural to split off  into teams covering specific 
> areas.  The idea is that you never have just  _one_ person who knows how 
> to work on a piece of code.

Isn't it a goal of XP that all developers know a bit about all parts of 
the system?  Not in details, but a basic understanding of what that sub-
system does and how they do it.  That is what I've been told/read.
 
> >In these cases you could do each subsystem as an XP project, and the only
> >thing about the other parts you care about are the interfaces to them.
> >
> Exactly.  There is no way to get around that.

In XP I agree, but tht is not true of all design processes that I have
been involved with.  One process I followed did scale to all levels. 
Part of the process was a tailouring exercise were you worked out what
parts of the whole process where apporpate.

We both agree that breaking a larger project down until the parts become
manageable is the correct think to do.  I can't see that you would 
disagree as that is how software engineering has been done for years and 
years.  But what do you see as being the control process at the top level.
I don't see how XP can manage at that level as it is very focused on 
code production.  This is why I'm confused as to why to think that XP can
scale.

Steve D