Ok, so that didn’t work so well…

OK, my idea of posting every night from the conference didn’t go so well — each night I ended up having so much information to process that there was no way I was going to be able to come up with an entry. I’ll work on processing more this week and try for a post on the highlights of the conference (at least for me). From there, I’ll move on to discussions of my initial thoughts on some new topics.

Let’s try this again — Agile 2005 Day 0

Obviously, it’s been a while since I’ve posted. OK it’s been longer than a while. I’m sorry for that. Obviously, the promises of resuming posting didn’t work like I intended them to. Blogging is something I’d still like to do. Maybe this time it’ll take off. No promises this time — we’ll see what happens. For those who have hung in there (either consciously or by simply never removing a subscription to the RSS feed), thank you.

Anyhow, this week I’m in Denver, attending Agile 2005. While I have a few complaints about speaker treatment, and the hotel is overpriced ($5 for a bottle of Evian in the rooms? $3 for using the lobby wireless for 15 minutes?), I’m excited about it.

Since the blogging from Agile Fusion was a big hit, and it got me to think about some of the things more deeply than I otherwise might. I’d like to try that again in this venue with a few changes. Last time, I felt like I didn’t participate as much as I could have because I was blogging so much — it was the same thing as when someone is photographing or videotaping an event — the camera (or laptop) gets in the way of participating. This time I’d like to avoid that — I think a conference format is probably a better place for that — there’s sessions & then breaks. Since I may only be able to post from my room (it’s not clear whether there’ll be free wireless for the conference), I think that will help with this.

So, starting tomorrow, I’ll be making posts about my experiences here. From there, we’ll see where this all goes.

*bzzt* *bzzt* Resuming broadcasting…

It’s been two months since I last posted here. I got out of the habit about the time that I left MN to go back down to FL for the school year, and have been playing catch up ever since. It’s been something that has been high on my todo list, but never actually accomplished for a while. Now, I just finished attending the the Pacific Northwest Software Quality Conference in Portland, OR. Since I told quite a few people about my blog, and I’d like it if they actually wanted to read what I have to say, and this requires that I have something to say for them to read, it is definitely time for me to post. The first thing I want to talk about is a rundown of the projects I’m working on. All of these are things that will probably be showing up in future entries.

1. Classes — I’ve got three classes that I’m registered for this semester: Computer Networks, Fundamentals of Computer Security, and Swarm Intelligence. Things are going well in all of them.
2. Swarm Project — In my swarm intelligence class, there are only two students. We each have a project we’re working on. Mine is to create a simulator where robots try to find their way out of a room with inner walls making things more difficult. There will be 5 different controllers to pick from. The first is each robot simply wanders around randomly. The second method is for the robots to have a shared mental map that they use to navigate. The third has each robot maintaining its own map and broadcasting wall locations to robots within a certain radius when it encounters a new wall. The fourth way keeps the individual maps, but robots only share information when they collide. The fifth way is to actually use a swarm intelligence method. The robots initially wander around randomly but they remember the path they take. When a robot finds the door, it lays down a pheromone trail along the path that it took. When the other robots come across the pheromone trail, they may or may not follow it (the stronger the pheromone, the more likely they are to follow the trail). Originally, this was going to be done in Java with a Java3D UI in front of it. Now it’s looking like it might be done in StarLogo (which will be far easier). The plan is to use the simulator to determine the benefits of the various approaches in terms of efficiency in getting the robots out.
3. Dissertation/PhD — I haven’t completed the application for the PhD program yet, but I’m making some progress on the dissertation side. I recently finished reading Robert Sternberg’s Thinking Styles which describes his theory of mental self-government. According to the model, a person is going to prefer to be executive (doing things), legislative (creating things), or judicial (critiquing things). Then, within that preference, a person will be monarchic (focused on one goal and one goal only), hierarchic (having a structured hierarchy of prioritized goals), oligarchic (split amongst multiple goals without a clear sense of priority), or anarchic (no clear focus). A person will also have a preference between conservative and liberal (not the political leanings, but I forget what they mean in the model at the moment) and a preference between global and local (big-picture or detail oriented). I liked the book quite a bit actually.
4. Blog admining — I’ve taken over the job of blog admin for the lab. We had a recent incursion of comment spam, and I’ve been learning how MovableType works.
5. TAing — Cem is teaching a course on test-driven development and I’m his teaching assistant.
6. Other miscellaneous things — I’m involved in various other projects around school too.

   So, I’m staying busy. Things are good though and I’ll be resuming posting on a more regular schedule again.

   Coming next: a post about PNSQC.

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.

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