Marin Java Extreme Hour

The next meeting of the MarinJava Discussion Group will be this coming Wednesday, January 26th, 2000 at 7:00pm at Royal Ground Coffee in downtown San Rafael, Marin County, California, USA. (Marin County is on the other side of the Golden Gate Bridge from San Francisco.)

We'll be trying the ExtremeHour ExtremeProgramming exercise. We'll attempt to spec, design and ship a hypothetical product within one hour of ideal engineering time, using all the ExtremeProgramming practices.

To prepare for this exercise, please check out the ExtremeHour page for general information, and the MarinJavaExtremeHour page (this page) for information specific to our group. You may also want to review some of the ExtremeProgramming resources listed on the MarinJava website http://www.jera.com/marinjava/

Definitely plan on showing up for this one. I'm still kicking myself for missing the SiliconValleyExtremeHour last December.

Feel free to post any questions or comments to the mailing list mailto:marinjava@egroups.com, or edit them onto this page.

-- JohnBrewer

So far, we have several candidate ideas for a product:

Automatic diaper changer (an AmericanCulturalAssumption -- others might call it a "nappy changer"). Just the thing for yuppie scum: all the fun of a baby, but none of the mess or smell. When baby needs a change, just lower him/her into the automatic diaper changer and let the machine do the rest. Possible product liability issues mean a high quality process and extensive testing are essential.

A programmer beverage delivery system. At most software companies, programmers get free soda. However, programmers waste valuable time getting up from their computers and walking to the break room to get soda. Management would like an automated system whereby programmers can request a beverage from their desk and have said beverage delivered to them in a timely fashion, thus allowing programmer to work uninterrupted.

We also toyed with doing a real (but tiny) software product, but decided the infrastructure issues were too complex.

Any other suggestions?

-- JohnBrewer