xmlwiki-developers

[xmlWiki-developers] coding issues

[Arnaldo C. <ar...@mi...>]

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:
    -->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 if you feel =
like it.
    -->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.
        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.
        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.
    -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.
    -Someone will need to document our initial design in UML, and send =
it to the group.  Any takers?
    -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
   =20

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

Re: [xmlWiki-developers] coding issues

[CS327 TA <cs3...@cs...>]

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

Just thought I might cut in here...

Actually, I have seen people like Ron Jeffries argue very strongly that
the "architecture" emerges through refactoring *alone*. Certain people in
the XP camp have come out very strongly against any sort of up-front
design (not sure if I agree with this), especially involving the use of
patterns (which is more sensible, IMO). One can see another example in the
ObjectMentor "Bowling example" we have linked to off the course wiki -
there is no CRC involved there - the design emerges through writing those
tests, and the discussion that happens while the developers are sitting
down coding, not before.

Of course, these are all well and good for small toy examples like Bowling
Scores... and in your case it may be more appropriate to do some design up
front, especially since your team requires more synchronization and can't
just ask strike up a group-wide design discussion at any one time. So, I
would say Hugo's view is perhaps pragmatic, but not necessarily the party
line.

Be sure to write up issues like this, the pros/cons of each option,
why you did what you did, how it worked out for you, etc. for the
end-of-semester write-up.

 - Andrew.

Re: [xmlWiki-developers] coding issues

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

In the thread titled "Subject: [XP] Exactly what IS _big_ design up front? " http://groups.yahoo.com/group/extremeprogramming/message/37522 you can find a recent discussion about design. 


--- In extremeprogramming@y... <http://groups.yahoo.com/group/extremeprogramming/post?protectID=070082114180056192184147109024192012134152211241039019161126172205142>, drawstho@a... <http://groups.yahoo.com/group/extremeprogramming/post?protectID=114212113105099134170149203140129208071> wrote:
> So, there seem to be two schools of thought:
>   1. do enough design to get started with the first iteration, 
> knowing that you will be doing more in each iteration as you go 
> along, and
>   2. do a (relatively complete) first draft design up front, 
> knowing that it will be modified in each iteration as you go along.

Instead, let me suggest these three schools:
1. Do only enough design to be able to do the first task (or story)
2. Do enough design to be cover the first iteration
3. Do a complete (draft) design that spans multiple iterations

I would put XP in the first box, "true" RUP in the second, and both 
waterfall and RUP-as-often-practiced in the third.

I suspect that almost everyone here would agree that 3 is BDUF (Big 
Design Up Front). People (like me) who really like XP and Test-First 
Design would tend to label 2 as also being BDUF, but many other 
people would simply consider it to be DUF, or JEDUF (Just Enough).

Kevin




================

-H

cs3...@cs... wrote:

>>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.
>>
>
>Just thought I might cut in here...
>
>Actually, I have seen people like Ron Jeffries argue very strongly that
>the "architecture" emerges through refactoring *alone*. Certain people in
>the XP camp have come out very strongly against any sort of up-front
>design (not sure if I agree with this), especially involving the use of
>patterns (which is more sensible, IMO). One can see another example in the
>ObjectMentor "Bowling example" we have linked to off the course wiki -
>there is no CRC involved there - the design emerges through writing those
>tests, and the discussion that happens while the developers are sitting
>down coding, not before.
>
>Of course, these are all well and good for small toy examples like Bowling
>Scores... and in your case it may be more appropriate to do some design up
>front, especially since your team requires more synchronization and can't
>just ask strike up a group-wide design discussion at any one time. So, I
>would say Hugo's view is perhaps pragmatic, but not necessarily the party
>line.
>
>Be sure to write up issues like this, the pros/cons of each option,
>why you did what you did, how it worked out for you, etc. for the
>end-of-semester write-up.
>
> - Andrew.
>
>
>_______________________________________________
>xmlWiki-developers mailing list
>xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xmlwiki-developers
>