Triangle Xp Meeting One

Minutes for the first meeting of the TriangleXpUsersGroup (Monday October 28th, 2002 6.30pm-8pm)

People (please add your names): (I counted an attendance of 34)

Here are the topics I jotted down from the board at the first meeting. If I missed any, please add them.

(A) Unit Testing EJBs
(B) Is there such a thing as too much unit testing? (or CanYouHaveTooManyUnitTests) [7]
(C) Coaching/Selling/Teaching XP [9]
(D) Introducing XP to New Teams
(E) Doing XP as a black ops project [6]
(F) XP Intro [12]
(G) JUnit and Portlet htmlunit
(H) What XP tools do you use?
(I) Pair Programming in Practice

Topic F - XP Intro. Note taker - WayneJohnston. These notes hopefully capture the essence of our discussion but definitely not every aspect.

Our group of about 10 people stayed together pretty much intact the whole meeting time. We also touched on topic C (which includes 'selling' XP) and topic E (black ops, meaning secretly doing XP).

Questions we discussed:

What is XP?

Who does it? Several people mentioned doing pieces of XP at least periodically.

Why do it? Some reasons mentioned included that it expands one's breadth of knowledge, prevents there from being just one expert in an area, and gives feedback to management on progress by how many tests are passing.

An XP team should encompass all functions.

XP is a coherent process for software people by software people, not an imposed methodology.

The sub-topic we spent the most time on was pair programming. Some people mentioned having two keyboards, mice, and monitors as opposed to having to switch hardware or seats when changing the "driver".

How often should you switch pairs? Half days seemed most practical. The challenge is to break up tasks to be completed in that time.

How to deal with personality mismatches? That one was hard. You have to communicate in XP, so get it out in the open.

How to deal with differences in skill level? That should not be a real problem. When it occurs, it is an opportunity for mentoring and learning. You must not be too proud to admit you don't know something, or to have it pointed out that you made a mistake.

Many times companies don't train, or training isn't effective, and pair programming can be a substitute.

End of pair programming topic.

Don't overdesign up front - it slows you down.

How to fight bureaucracy/methodology that dictates overdesign? Maybe you can be an agent for change and try XP on a small project. If you aren't allowed to make changes, at least get your manager to agree the current methodology is stupid. Maybe go through motions required by methodology but really do XP behind a facade.

Perhaps managers impose a methodology which slows things down but at least they gain predictability. (That's what they think they are doing. There are more risks associated with expanding the schedule. -- MitchAmiano)

Topic B - Is there such a think as too much unit testing? - I don't think we designated a note taker, but I've had a first go at jotting down notes I made in the topic CanYouHaveTooManyUnitTests. I would encourage other participants in this discussion to add their notes. -- AlexChapman

Topic E - Doing XP as a black ops project. - No designated note taker.

I work at a startup where the focus is on functionality rather than thorough testing. When you are in a race to attract investors, shortcuts are necessary. I can understand (and believe) how many of the XP practices can achieve rapid closure to functionality but convincing my peers/managers(:P) of such is not easy. Moreover, in this dog-eat-dog marketplace, rowing against the stream is also risky. So, without a mandate or tacit approval for using techniques outside the norm, using XP is most certainly a black-op. To date, I have not failed to meet expectations, either for quality or schedule, but it it starting to get dicey. Wish me luck. -- RickyWest

Topic I - Pair Programming in Practice - Notes by BillKrebs

I heard some interesting points that we new to me. One was what effect does monitor size and resolution have on code? Some people code at special split machines with one CPU and two monitors and keyboards. That speeds up pairing because you can type at speed and make a slight noise to indicate to your partner you're stuck and ready to trade. Most folks use one monitor and shove the keyboard back and forth. This can be tricky if you don't have much room. The screen size issue depends on people's ability to see tiny fonts, but if you have a big screen does this encourage methods that fit on a screen and use both the vertical and horizontal space? or do you get small readable methods from a medium size screen were people have to divide their methods into sub pieces?

Another point was the effect of office layout. Configurations can range from a cell small enough for one person were you have to walk across the hall to your partner's office, to a large open space were you can just look up and talk. Where I work, we have very nice cubicles, with a feeling of privacy when you want it but with easy access to other people by walking a few feet. The cube is big enough to seat two when we're in pairing mode but it's a bit awkward because it's a skinny rectangle shape instead of a square.

We touched on the supporting coding standards and collective ownership practices in that they quickly become important and second nature when the team does pairing. Ideally, you would not be able to tell who wrote the code, and would not have to run beautify each time you edit another file to get it to look 'right' (and undo someone else's beautify).

We have folks new to XP that were keen to learn more, but also some experienced hands that would not dream of writing any code without their pairing partner nearby.

There are some people who have an independent cultural mind set of being an individual recognized for their work. It's hard for them to get used to pairing. They want their contributions to stand out. This may be good for them, but we question if it's best for the team as a whole. Still, some teams allow a few reluctant individuals to go solo while most others pair.

I think reading "Pair Programming Illuminated" by Williams and Kessler helps people prepare before pairing for the first time. They can start with their eyes open and avoid a bad experience that doesn't reflect on XP as much as not knowing how to do XP well. The book points out that many combinations can work - Expert Novice, Expert Expert, Novice novice, etc for different situations and goals.

We also had some interest in comparing how many tests different teams had, and if they introduced XP in immersion mode or a little at a time. So, we'll have plenty to talk about next time.

-- BillKrebs