View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Extreme Programming Case

by: L Sparks

note:  key topic of each paragraph is in Bold

Extreme Programming is a set of Rules and Practices used in program development.
XP is touched on in the latter stages of both the cs2335 and cs2340 courses. I think that this is a
very valid concept and should be explored early in the course of program development. Many of you may
actually already practice XP without really knowing that you are doing so. The purpose of this case page
is to give you an understanding of the different concepts that XP touches on and how we benefited from
them or vice versa. The Pip Squeaks used a great deal of Extreme Programming during the course of the
SimTech Project Development. Below you will find how XP helped our group succeed in cs2340. I will also
try to give valid examples from our experience where applicable.


    The first idea that we had initially tried to do was the
iterative process.  The iterative process is where you set up user
stories for that particular phase of development.  You want to make sure
that you only schedule the most important things for this phase only.  You
do not want to look ahead or design for the future.  In order to make sure
that you are meeting the requirements for the phase you are able to compare your
progress with the schedule you came up with during your scheduling meeting. 
This particular phase of the extreme programming was very difficult for us to
achieve.  We did not meet deadlines that we set forth for each of the
phases and instead of calling new meetings to reschedule and fix our time
schedule we continued with the original and had no way to analyze our progress
at that time.

    The next thing that we did was we were able to move to
different areas of our program.  Moving people is important because
it creates a team that can code at any level or any area of the program. 
This helps keep you from being one dimensional.  The example that they give
on the XP site is if someone leaves the company.  Our fear was that one
person's schedule may get crammed or if someone were to get sick we all had an
idea of what was going on.  This worked well since our team had two a.m.
programmers and two p.m. programmers.  We were able to start jobs and pass
them on to other group members to finish.  This also was good when it came
time to merge code.  Our code merging was very smooth because we all new
what was going on with each others code.

    I had never heard of stand-up meetings until my first
lecture on XP.  Stand-up meetings worked really well in our group. 
Mainly because we didn't like sitting in long group meetings when we first got
to campus in the mornings.  What we tried to do was meet briefly in groups
of at least two.  The groups usually consisted of the group members who
were working together so they could discuss what to do for the day.  This
worked well because it was like a many design session that made sure we were on
the same page in our design.  We made sure to meet as a full group at least
once a week for a brief 10 minute meeting in order to catch up and build to the
next phase of our design and coding projects.


    When in design phase it is important not to design ahead. 
You do not want to add stuff until it is needed.  This is important because
what we found is that theory is correct.  They state that 90% of your time
will be wasted because you will use 10% of your code.  Early addition of
caused a lot of problems with our code because we weren't sure what was
used and what was not.

    CRC cards were used by our group as a reminder of


    The main thing we found that worked best for us in
our SimTech programming was paired programming.  This concept puts
one person at the wheel and the other person as a backseat driver.  This
works well because in the beginning we were able to put the least knowledgeable
squeakers at the keyboard while the other person walked them through code. 
This proved beneficial because we were able to get code done with less code
research.  We lost some time but not as much as we would have had on the
research.  The other positive is that the driver is able to learn the code
and get the feel of the squeak environment at the same time and weren't stuck
hacking squeak by themselves. 

    We decided to use pen drives and the coweb for integrating code because we found that cvs was difficult to manage since squeak can be merged at the method level and not just at the class level. See Michelle's page on using pen drives here .

    Creating your unit tests first proved beneficial
for us because we were able to decide the desired functionality before really
coding any of our project.  By doing this planning we were able to run the
tests as each module was completed and feel comfortable that it is workable code
if it passed the tests.  Our backend was very solid and was integrated
easily with all other code because the error checking and functionality was
solid.  We were able to focus on the GUI from M3 on because we knew that
our backend would not break.

    One problem we encountered in coding was the desire to
optimize early in the process.  This cost a lot of time and some of the
was later overwritten.  My advice is to code it to working
stage and then optimize based on what you have.


    As far as testing goes you can never have too many
unit tests in my opinion.


If you would like more information on XP visit their site at

Links to this Page