More observations

* Brian observed that it was interesting pairing because it seemed that at any given moment he wasn’t as confident in the code and his understanding of the code as it has historically been on his own (but as long as the sum total of confidence was ok, he was ok with that). He attributed it to test first design — in the early 80s, he’d think lots about the problem before writing code and the code would just flow out, but now when he does test-first programming, he doesn’t have as full an understanding of the code because the tests understand the code for him in some ways. Mike said the understanding is still there, it’s just written down in the tests. You don’t need to keep it all in your head, and when you need the understanding you don’t have in your head, you can go back to the tests and “re-inflate” the parts you need.

* He also observed that we got caught up so that the code was beginning to drive user level decisions until he pulled the pair back. He finds that same cycle in his own personal programming — coding distracts him from thinking about what the user would want and he needs to consciously pull himself back. He asked if there was a certain art or skill to diving into the code, the code tells you what it can do, then you go back to the customer level, and back and forth, having it all come out nicely. Mike said taking breaks sometimes has been helpful for him. Bill also suggested keeping the customer in the room helps with this question of focus.

* Mike H. observed that installing stuff is a big pain in the butt. He was surprised at the number of things he had to install and configure in his work today on the install procedure. Mike mentioned an interesting thing to consider — how many projects start the install stuff in parallel with the application development. He thinks there might be some benefit to doing that.

So, now we’re breaking

BC’s thoughts on Ruby

BC posted a writeup over on her livejournal about her thoughts on Ruby after this week. Her post also makes me remember that none of my LJ friends show up on my blogroll…. need to do something about that perhaps.

Anyhow, here’s BC’s post: http://www.livejournal.com/users/bcholmes/56382.html.

Update: Fixed the link. An extra colon migrated in

Day 6

We discussed a little more testing this morning. I was still waking up, but here’s what I pulled out as key points in the discussion:
* End to end tests put the other tests in context
* 3 categories of tests: programmer, customer, tester
* Testers might look for risks that wouldn’t occur to the programmer

Cem also said I should write about the XP principle of a 40-hour work week, and how our blatant disregard for this principle has affected us. We’ve been doing roughly 12 hour days every day (though we did take Sunday afternoon off — some of us went looking for a geocache supposedly on the Appalachian Trail. I say supposedly because even with TWO GPS receivers, a laptop running Microsoft MapPoint, a large number of cell phones (which did nothing to help with the caching, but still….), and who knows what other bits and pieces of technology the 7 of us had, we couldn’t find the cache. Oh well — we had a nice walk in the woods .

Anyhow, back to the 40 hour thing. It’s been obvious every day that people are getting more and more rundown. I haven’t gone back and read my entries but I’m guessing there’s a noticeable progression of quality decreases. I took some time off at dinner last night to play some pinball which helped a lot. Not sure what others are doing to recuperate. Anyhow, so now I’ve mentioned the effects of ignoring the 40-hour work week prinicple.

In other news, we have had a few pictures being taken this week. I don’t have image editing software on my laptop at the moment, so posting of these pictures will have to wait until I get back to MN (unless I can co-opt someone here who has said software to reduce the size of the images for me). Rest assured at least a couple will be coming, however.

We’ve been using quite a few books this week as well. Here’s a list of the books that I’ve found floating around (can you tell that we’re close to wrap up point and no one needs my help on their stories?) The books are listed in the order I found them as I walked around the table. I haven’t heard any complaints about any of them that are springing to mind at the moment:

• The Java Developer’s Guide to Eclipse by Sherry Shavor, Jim D’Anjou, Dan Kehn, Scott Fairbrother, John Kellerman, and Pat McCarthy
• Ruby in a Nutshell by Yukhiro Matsumoto
• The Ruby Way by Hal Fulton
• Programming Ruby: A Pragmatic Programmer’s Guide by Dave Thomas and Andy Hunt
• Ruby Developer’s Guide by Robert Feldt, Lyle Johnson, Michael Neumann (Editor), and Jonothon Ortiz
• Eclipse in Action: A Guide for the Java Developer by David Gallardo, Ed Burnette, and Robert McGovern
• Google Hacks by Tara Calishain and Rael Dornfest [I think this might have been a "someone was being shown this book" rather than a "we used this book" -- as far as I know, we didn't do anything with google]
• HTML & XHTML: The Definitive Guide by Chuck Musciano and Bill Kennedy
• SAMS Teach Yourself Ruby in 21 Days by Mark Slagell [When I wrote this post, this link wouldn't load at Amazon for some reason. I could get everywhere else on the site, but it wouldn't give me the detail page for this book.]
• Learning Unix for Mac OS X by Dave Taylor and Brian Jepson
• Mac OS X Jaguar: The Complete Reference by Jesse Feller

There was also one Ruby book that got removed from circulation pretty quickly. I haven’t looked at it, but was told that the book Making Use of Ruby was not worth the money that had been spent on it.

Observations

Tonight we spent the after dinner session taking a first crack at describing what we’ve learned from the session so far. I imagine we’ll be revisiting the topic again in the next couple of days, but here’s the slightly annotated list of points we came up with tonight…

• Managing XP with cards is like chartered exploratory testing
• Easy to pair program with people new to pair programming
• Testers seemed like programmers when pair programming
• New environment + code led to thrashing
• James wants to pair for an hour or so where his role is specifically to be a tester rather than a programmer.
• Testing requires different mindset than programming (“How does this work incorrectly” vs. “How do we make this work as simply as possible?”)
• Still need a system testing phase
• Purpose of pairing is to make life easier for both developers and testers (developers can fix bugs while they’re still focused on the code, testers don’t have to repeat work because they know what testing the developers did)
• Pairing can improve trust between testers and developers, and increase efficiency. Less looking over shoulder and more doing something collaboratively
• Acceptance testing is a pain to setup
• Need standard approaches (cookbook/patterns) for acceptance testing
• Hard to remember to unit test when developing your acceptance test framework
• Hard to know whether unit testing for an acceptance testing framework is needed
• Lack of commercial support for open source dev & test tools leads to wasted time
• Able to cite examples to refute nonsense about XP/testing
• Training, experience, and instincts in testing don’t necessarily translate well into unit testing (instincts tell us to filter out tests that are too trivial)
• Change detection is different than testing
• Identifying opportunities for useful unit tests is a skill worth learning
• Developers seem to be working with more junior testers
• Testers don’t have to be adversarial
• Inclined to thinking more about magic tricks as metaphor for thinking about tests (You watch a trick, and what did you see?)
• Different metaphor = law enforcement investigation (testers as detectives)
• Learned why pair programming can be an advantage (John made an observation that ours is the only profession where it is considered abnormal on two people working together to solve a problem, Cem suggested lawyers as another and doctors for anything which does not require litigtaional support, then asked to what extent the practice of consulting others in medicine is the result of being sued for malpractice)
• There are many types of testing some of us didn’t know about — both crazy and interesting
• Good exploratory testing does not mean “monkey sitting at keyboard”. Instead there’s a discipline and structure to it.
• Exploratory testing articles: James’ “Exploratory Testing Explained” and “Exploring Exploratory Testing” (which Cem and I wrote for this year’s STAR East conference)
• More rigor to than some of us realized. (Comment was made in reference to James’ Satisfice Heuristic Test Strategy Model
• Recommendation of How to Solve It by George Polya and other works by him as well.
• Really interesting we didn’t use FIT, and we need to explore why. It was speculated that had Rob Mee been here, we might have focused more on FIT.
• Testing is messier than XP admits
• Acceptance tests may be written like unit tests
• FIT Might still happen
• Regret that we didn’t use FIT
• Eagerness to code deferred acceptance tests
• UML finally makes sense when animated
• Excited by “Iron Man CRC” (aka “Naked CRC”) (don’t write anything down, but use blank cards to move things around) [Editor's note: I missed this. I'm going to try to get a private showing, but until then, I don't know anything more about this ]
• Happily surprised pairing was as comfortable as it was
• “Tipping Point” — (This is mine, so i get to explain it here. We couldn’t get it to a succinct bullet point that I liked. What I was trying to express was that while I’ve been aware and fairly comfortable with agile development practices, they hadn’t crystalized into my style. I could look at a project and see how agile techniques would work, I could follow the reasoning for the benefits, but I had to consciously decide that I was going to use agile development principles on any given project. After this week, it feels much more like a natural thing for me, and I think I’ll be building agile practices into my personal all-the-time approach to developing.)
  Distributed pairing (Chris does this as his job — team is colocated with the exception of himself. He’s found that remote pairing is no less efficient than when he’s on site. He uses these tools: WebX, PlaceWare, NetMeeting, and VNC. He’s presenting a paper at ADC next week that he thinks he can send out once the conference publishes it. For him, Placeware has been the best, but it’s also the most expensive. His team uses standard phone lines for the audio portion (they all have headsets)).

  At this point, we declared a night.

Metrics in XP

This post is in more of a notes style than my previous ones. I was originally planning on making this more prose-like, but I’m not going to after all. I kind of like the way it reads now. Maybe it’ll lead to more questions, but I’m going to call it a blogging experiment.

Cem raised a question of metrics in XP and how the perceived lack of metrics can lead to some testers flipping their “bozo bits” on XP
Mike -> some teams do, question of personal actuals (for performance reviews) vs. knowledge of peoples’ skills gained from pairing
Jeremy -> A project’s goal should be to have zero bugs. Don’t have thresholds of “okayness” since the bugs below that threshold may be hiding other bugs.
Cem -> “OK, as long as you’re not doing maintenance” — depends on whether project started immediately fixing bugs or you’re dealing with legacy code that comes with a backlog of bugs.
James -> a dedicated testing staff *will* create bug backlog, plus there’ll be controversial bugs that can’t be immediately fixed until something is resolved (possibly needing conflict resolution between two stakeholders or other similarly time consuing processes)
Mike -> key thing you want to know is injection rate from developers
James -> one thing that is a big problem: Projects ship with open bugs (bugs for which no decision has been made), therefore Borland had policy when James was there of “always ship with 0 unresolved bugs” (a resolution may be to decide not to fix it)
Cem -> different kind of backlog that you might run into with some more experienced testers -> high volume test automation (use computer to generate lots of tests) finds complex bugs (stack overflows, pointer problems, etc.) that take a long time to troubleshoot. Cem created new category for tracking these defects (called Dumpster, used to avoid metrics counts that penalized the team for leaving a bug open) used for defects that were hard to reproduce/troubleshoot. Every week, one programmer and one tester would go “dumpster diving” and try to find patterns. Thus, there are some situations in which a backlog is fundamentally necessary (to get the patterns to fix the complex bugs).