[Sussex] Re: Gentoo problems.

[Geoff Teale]

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.

>All project need "enlightened management."
>  
>
Hear, hear!

>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.

>>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).

>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.
>  
>
Yes.

>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).

>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.

>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.
>  
>
Exactly.  There is no way to get around that.

-- 
GJT
gteale at cmedltd.com
tealeg at member.fsf.org