Re: [xmlWiki-developers] coding issues

[Hugo G. <xm...@ne...>]

Hey some comments.

ar...@mi... wrote:

> Folks,
>
>     We're both eager and close to replacing a lot of this planning 
> with coding.  I think the following issues will prove to be crucial to us:
>
Yes, me too, for future reference: it has been my experience that this 
is the part that can kill the willingness of a group implementing XP for 
the first time especially when they are on a short time frame. In a 
context where a short deadline is not hanging over the team then the 
planning sessions are how the team developes the architecture and the 
design of an application. Normally each of the session (user stories, 
release planning, iteration planning ) take anywhere from one good 
afternoon to one full day. This may seem a lot BUTwhen compared to 
things like RUP you will find that you can spend days (weeks) in each of 
the initial phases (requirement gatherring, etc).

>     -->Refactoring<--  XP is known for letting the architecture 
> "emerge".  This will only happen if we're diligent to "refactor 
> mercilessly", one of the central XP practices.  Briefly, this is about 
> having well-organized code, and constantly reorganizing it to the next 
> level.  I think we all know what well-organized code is, but for 
> interested parties, you can check out www.refactoring.com 
> <http://www.refactoring.com>  if you feel like it.
>
The program doesn't necesarily emege by refactoring alone but by 
refactoring an initial design. This is where a small CRC session fits in 
not only at the group level but at the pair level. Refactoring doesn't 
address design, what it addresses is makiing existing code better and by 
merciless refactoring the code then the design a.k.a the stucture of the 
program is refined. But by the point you get to coding the design as 
"emerged" through the various planning games that the developers have 
particapated in.

User Stories                        ---->            Engineering 
Taske                ---->
(Very General Design)                            (Less General 
Design)                           

Aceptance Test/Unit Test                            ----->             
    Code
(Less General and More Specific Deisgn)                            (Very 
Specific Design and Structure)

----> Refactoring
        (Better Design, Best Structure)

>     -->Practices unique to our group<--  An environment where we're 
> all in the same room is very beneficial for XP.  To make an XP project 
> work with everyone spread out, we're all going to need to commit 
> up-front to our own set of practices.  I think that these should be:
>
>         a)After every coding session, email the group and summarize 
> what you did.  This way we all have a gist of the code's current state.
>
Do you guys feel it would be practical to do a "pseudo standup meeting" 
 before you code. This could be set up as a wiki page in the course wiki 
where we could keep a log  and everybody can see where we are. For 
example this would be by stand up meeting entry :

"Yesterday, Chis and I got together and use VPN for our programming 
session. We mainly spent the time setting up all the java stuff that has 
to be downloaded in order to work together. We found that VPN refreshes 
fast IF the background is kept black. I set up Forte for Jim and showed 
him very briefly how to use it by setting up the inital class in the 
JUnit Cookbook. Before I next programming session I will write up the 
initial accptance test for the Browse user strory."

Stand-up meeting are an integral part of XP. It is how XPers  start the day.

>         b)We've assigned groups different portions of the code, and 
> this is probably a necessary evil, since we're all spread out.  But, 
> keep in mind the XP practice of collective ownership.  Feel free to 
> step outside the box of what you've been assigned and to work on 
> something else...just let the group know what you did.
>
The necesary evil is actually how it works. We as a group have assigned 
pairs at the story level. We did this in order to try to code as fast as 
possible. Normally, the developers of a group request to do a particular 
engineering task ane THEN you pair with whoever wants the task too. For 
a first go at XP this minor and also our strories are fairly simple so 
this minor refinement of XP should not pose a problem.  Maybe for the 
second iteration we can then pair off at the engineering taks level 
since then it is easier to rotate between pairs.

>         c)Log into our xmlWiki chat space whenever you're coding.  
> This way you can ensure that no two pairs are changing the same 
> portion of code simultaneously, and you can ask questions to other 
> people currently coding.
>
>     Let's try and agree to commit to these (or change them) up front.
>
>  
>
> Tonight's 8PM CST meeting:
>
>     -Quick discussion of above practices/buy-in/change.  This should 
> take 10 minutes, *tops*, hopefully more like 5.  If you disagree, have 
> something to add or change or eliminate, speak quickly or forever hold 
> your peace.
>
Kent Beck and others have commented that as long as you follow the 
twelve practices of XP then you are doing XP. How many of them are we 
doing? We should be able to do 11 of them by the end of the term.

http://www.c2.com/cgi/wiki?ExtremeProgrammingCorePractices

>     -Initial design discussion.  According to "XP Installed", this 
> should take no more than 10-15 minutes.  I say we should give it 30, 
> tops.  Again, under XP, we should expect the first architecture design 
> to be wrong anyway, and if we refactor mercilessly, it will be easy to 
> change.
>
This would be true if we were all good in server side Java programming 
and XML/XSL/XSLT. But some of you do not have the language to 
communicate confidently about the technology. For example when I say 
"There is going to be a servlet that will authenticate the user against 
the LDAP server and then initate a Session." I can almost see the code 
and in some cases a pattern to use. I know which API's I will use and 
what classes to instanciate and which methods to call.  For those 
particular cases where I may be rusty then at least I know where exactly 
in the JavaDoc to look to refresh my mind. In some cases I also know 
where to find a small snipplet of example code.  IF we were all at this 
level THEN I would feel confident that we could dispense with a CRC 
session because we could communicate in English and know in code what to 
do.  I do not think that the design meeting is going to be a short one.

>     -Someone will need to document our initial design in UML, and send 
> it to the group.  Any takers?
>
It would be interesting to see the intial plan and compare it to the 
refactored design after the each iteration.

The UML can be done from the code by using TogetherJ ( 
http://www.togethersoft.com ). The only problem is the first one class 
diagram.

>     -Since we're moving into coding, I think our meeting lengths 
> should be drastically reduced at this point (at least until the 2nd 
> iteration).  If not, we're doing something wrong.
>
>  
>
> --Arnaldo
>
>    
>