I just took a brief look at what NetBeans 4.0 will bring to the table. NetBeans has always had a slight advantage in its support for out-of-the-box J2EE development but everything else has dragged a mile behind Eclipse, in my opinion.

So, what were the things I saw that made me blog about having visited a web page?

Well, it looks like the NetBeans team is finally adding some refactoring support, which is a Good Thing™ but the number of refactorings implemented is not something to bragg about (it's also interesting that they consider "Find References/Declaration" and "Go to super implementation" to be refactorings ).

Oh, and is it just me or is NetBeans starting to look a bit like IntelliJ IDEA?

Clarke has again posted a link to some very interesting reading...

Joe Ely has posted a nice little story that describes the fundamental idea of Theory of Constraints quite well. But wait, there's more. It's also a nice story about why you should profile your code if you have a performance problem before spending a significant effort in fixing a would-be bottleneck.

Drum-roll, please...

It's Jonathan Schwarz with 2904 daily hits!

Just in case someone with an interest in image processing algorithms is reading this, I'd like to ask you to take a look at this discussion thread I started at JavaRanch regarding shape recognition. Any help is highly appreciated. Pretty please with sugar on top?

I just came back from kayak'ing for the first time in my life. First of all, nerds don't paddle so I'm kind of afraid of waking up tomorrow... Second, it's not too easy to keep direction with those things so I must've paddled a full 10 kilometers instead of the "5 or so" kilometers our guide estimated the distance. Oh, well. It was nice. And yes, I am keeping my day job :)

It's obvious that Andy's excited about Martin Flower blogging about his paper with Chris Stevenson (again, a very nice presentation guys!). Now if I could figure out who the heck is Martin Flower...? :)

When I heard that the final release of Eclipse 3.0 was coming just a few days after the last release candidate, I thought "oh crap, another 80 megs to download".

Well, someone up there must really, really like me because I managed to click on a mirror which served the 80 megabytes in approximately 15 seconds! Unzipping the archive took 3 times longer than downloading it. Geez. Thank you.

I know, you are reading the code you write. That's not the point. I'm saying
read the code you wrote 3 months ago!

I recently faced the situation where I would need to do a hand-off of a codebase I had developed with a co-worker (not pairing). After the mandatory PowerPoint session, we dove into code, stepping through the packages and classes in Eclipse using a projector. I couldn't help noticing that, today, I would do so many things differently. And the code was written just 3 months ago! I spotted a lot of duplication, misplaced responsibilities, pointless coupling, etc. which I had completely missed (or forgotten about) during development.

These kinds of situation make you realize how much pairing would've helped in terms of quality...

Hal posted some very nice links on trust over the weekend.

What would you expect from an article titled JUnit: Test-Driven Development? A short introduction into the theory behind TDD and a little story illustrated with code snippets from JUnit tests?

No, not this time. For some reason, the article -- of which title, to me at least, seems to stress TDD and not JUnit -- is actually nothing more than a JUnit tutorial. The word "test-driven development" doesn't occur once after the title and "TDD" occurs exactly once. In CONCLUSIONS!

Well, at least it looked like a good JUnit tutorial...

Here!

The official XP t-shirt

Brian Marick has just blogged about a workshop titled "the blindfold game", which neatly illustrates the importance of having frequent feedback -- short iterations.

Here's a quote:

I don't know exactly how have I managed to go for so long without knowing of the existence of PDFCreator -- an open source Windows printer driver producing PDF (instead of PostScript). I've only printed two PDFs so far but it seems to work like a charm. Check it out!

It looks like VersionOne is getting some serious competition from Rally.
This can only be a good thing!

Apparently, you can watch the World Chess Championship matches live online! I'm really not a fan of chess, but this sounds so cool that I guess I'll have to take a peek at some point...

Every now and then someone asks something related to "creating XML with SAX" in the XML and Related Technologies forum at the Big Moose Saloon. Obviously the answer has often been "write a SAX event handler which produces XML matching those events". A couple of hours ago, I (don't ask me why -- I probably couldn't tell) decided to implement such a SAX handler.

You can download the class from here and the JUnit test class for it here. Feel free to use it, bitch about code quality, etc etc. At least I had fun writing it :)

The class does have its deficiencies, including that it doesn't have any means of adding a DOCTYPE declaration to the resulting XML document. It doesn't provide any way to configure indentation either. If you want top-notch XML formatting, you better turn to XMLSerializer from Apache Xerces...

Here's a sample of how you would use the class for generating an XML document:

public void exampleUsageCreatingXmlDocuments() throws Exception {
	StringWriter sw = new StringWriter();
	SAXPrinter printer = new SAXPrinter(sw);

	printer.startDocument();

	// <ns1:root xmlns:ns1="urn:myns">

	printer.startPrefixMapping("ns1", "urn:myns");
	printer.startElement("urn:myns", "root", "", null);

	// <child>foobar</child>
	printer.startElement("", "", "child", null);
	printer.characters("foobar".toCharArray(), 0, 6);
	printer.endElement("", "", "child");

	// </ns1:root>
	printer.endElement("urn:myns", "root", "");
	printer.endPrefixMapping("ns1");

	printer.endDocument();

	// retrieve output from the writer and use it somehow
	String xmlOutput = sw.toString();

	// xmlOutput should be
	// <?xml version='1.0'?>
	// <ns1:root xmlns:ns1='urn:myns'><child>foobar</child></ns1:root>
	// but in a single line (no indentation)
}

Ok, ok. I know the seller who's asking nearly $40 for a $30 book probably set the price before Amazon.com started the "sale" but it got me thinking...

Are bookstores using Amazon's web services to dynamically set their prices according to what Amazon is asking? Should they?

Joshua has posted a catalog of patterns from his upcoming book, Refactoring to Patterns.

Let's see how many people can we get into the International Extreme Programming Meetup Day on July 5th!

testautomationpatterns.com looks like something you might want to keep an eye on if you're into automated testing.

I'm currently reading Domain-Driven Design by Eric Evans (a great book, by the way!) and specifically the part where he talks about modules.

Suddenly, Eric jumped into the limitations of the package concept of Java:

package packageA;

import packageB.ClassB1;
import packageB.ClassB2;
import packageC.ClassC1;
import packageC.ClassC2

public class ClassA1 { ... }

package packageA;

import packageB.*;
import packageC.*;

public class ClassA1 { ... }

Where am I going with this? I'm glad you asked.

While Eric certainly has a point (the main reason for importing individual classes is/was code readability -- to provide an easy way to figure out "which ContentHandler" a piece of code is actually referring to -- and with modern IDEs this is hardly a solid argument anymore), I'm feeling unsure about the true value of any particular way of arranging your import statements. The IDE handles those things for me. I just point the mouse cursor on the reference and the IDE tells me the fully-qualified class name for that particular reference. With Eclipse 3.0's code folding, I won't even see more than 1 line of import statements anyway :)

If you have some arguments (for or against) regarding Eric's suggestion, I'd be glad to hear them.

What? No, I'm not in Secret Service. I'm a happy beta tester for Google's GMail. Thanks Gregg! And thanks to Robert as well!

I'm quite excited about the user interface. Besides being very fast (might be due to the low usage levels), they've managed to create a beautiful UI with snappy DHTML for all sorts of folding operations. One of the things that surprised me was the threading concept (you'll see what I mean...). And, of course, seeing "You are currently using 0 MB (0%) of your 1000 MB." does give you a warm feeling close to having a clean Windows installation ;)

You can now reach me at lasse.koskela * gmail.com

Thanks to Clarke Ching, I found this great software development quote from Winnie the Pooh:

Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. And then he feels that perhaps there isn't.
        -- A. A. Milne

A friend of mine has one for sale on eBay.

How many times have you heard someone saying, "I don't care how you do it -- just do it!"

Personally, I haven't heard of those exact words even once, I think, but I sure have seen a lot of the equivalent attitude towards getting things done. Sometimes it has been me who has mentioned something about not caring about the 'how' as long as the 'what' gets done.

Sometimes we simply don't care about the 'how'.

Maybe we should.

The 'how' is an essential ingredient of sustainable business. You do care about that, don't you?

Are we going overboard with all this mobility stuff already?

More details from BBC News...

Andy Hunt just posted a blog entry that raises a couple of good questions targeted at proponents of repeatable processes which are the goal of certain SPI tools like CMM.

Here's a quote from Andy's blog. Try to put your prejudice and emotion away and really think about what he's saying.

Once again, someone made me realize how little I know about databases...

Michael Harmer, the Nerdherder, has something important to say:
Take baby steps (change one thing at a time)

Yes, you've heard it a million times before. Me too.

Yet, I still find myself repeating the sentence, "I just need to test it in the QA [environment]". Regardless of whether you do test-driven development or just (good) unit tests, there's always (well, almost always) something you don't have in your development environment. Still, we programmers tend to believe in our capability to avoid bugs that are due to differences in environmental issues like configuration etc.

You're not done until all tests pass!

And, remember what Mike said: take baby steps. Keeping your features small and going all the way with them will save you a lot of those "DOH!" moments.

Have we finally seen the end of it? (probably not, since they forgot to squeeze the three different IoC frameworks in there :-)

I still think the software industry would need a bit of this in order to improve quality.

"jaybaz" is telling a nice story about thinking out of the box. Check it out.

[ As promised, although a bit late, here's finally my own inside story of XP2004. It's all coming in one piece so make that trip to the fridge before starting... ]

XP2004 - The Fifth International Conference on Extreme Programming and Agile Process
6-10 June, 2004, Garmisch-Partenkirchen, Germany

About the Conference

The XP conference has been arranged for 5 times now. It all started with XP2000 in Sardinia, Italy, and moved around the Italian soil until XP2003. This year, the venue was in Garmisch-Partenkirchen, Germany. Next year, XP2005 will be in Sheffield, UK. The main conference was 3 days full of talks, paper presentations, panels, activities, a PhD symposium, a trainer and educator track, a slew of Birds of a Feather (BOF) and poster sessions, and a couple of workshops. In addition to that, there were two days before the conference fully dedicated to workshops and tutorials.

05.06.2004 Traveling to Garmisch

Finally in Garmisch-Partenkirchen, sitting in my hotel room… The trip went fine. The flight was on time, the food was good but hot (I burned both my fingers and my tongue…), and I luckily met Joshua Kerievsky on the train so the trip wasn't that boring. It really was a good thing to have bumped into Joshua in the train -- otherwise I wouldn't have anything left to read on my way back home...

I called Frank Westphal as agreed and headed out to his hotel for a late snack. The menu was less than satisfying so I had to settle for a soup and some assorted pieces of bread. Tammo Freese, Frank's buddy from his current gig was also there. We discussed about pretty much anything. Including flight simulators and Quentin Tarantino movies.

Oh, and their experiences of the hotel were rather conflicting. Frank had gotten an upgrade to a suite for free – just for arriving early, I believe – and Tammo had gotten a room with the scent of a dead cat. He had already started asking around for other accommodation the night he arrived…

06.06.2004 Workshop: "Be Empowered (and that's an order)"

For starters, Frank and Tammo picked me up on their way to the conference center so I didn't have to worry about getting a city map or asking for the way every 200 meters.

After registering for the conference in the lobby, I proceeded to the workshop room where the workshop leaders (Laurent Bossavit and Emmanuel Guillot) asked to take our shoes off, which, by the way, I think had a major subconscious influence on the openness of the attendants towards each other in addition to facilitating what we were going to do later on. The room had no chairs, no tables, nothing. Well, one table with the workshop leaders stuff on it and one "bench" where people could leave their bags etc. I'll come back to the "why" later on...

The real topic of the workshop was not empowerment (like the title might suggest) but self-organizing teams: Teams that organize themselves autonomously to optimize their way of working without external intervention.

Since most of the people were early, some of us got to introduce ourselves a bit before even starting (Charlie Poole, Diana Larsen, Rachel Davies, Marc Evers, Willem van den Ende, and some others). Brief introductions were given in a circle once everyone was present. There seemed to be a pretty even distribution of consultants and "regular" software developers. Then Laurent and Emmanuel discussed the objectives of the workshop and some of the participants were asked to tell why they decided to join this particular workshop. My reason (which wasn't asked for) was that I'm addicted to "people things" like behavior in varying social settings (translation: I'm an amateur psychologists:).

The actual workshop activity started with a warm-up exercise (a bit of stretching and yoga-style deep breathing) and we shortly proceeded to the first part of the series of exercises. The idea of the exercise was to have the group (team) exercise some self-organization in the form of arranging ourselves into a symmetrical circle where each of us is standing from an equal distance to the neighbors and seeing every person in the circle without moving your sight from the center of the circle. Once we had that pretty much working (it wasn't that easy), we added movement. The group was to walk the circle while keeping the same distance to neighboring team members.

After discussing the different phenomena present in the situation, we added more movements into the mix -- the group was to walk the circle and to be able to stop—as abruptly as possible while still keeping the distances. Later on we added changing direction, which proved to be a big difference since one couldn't see that easily whether the person initiating the move was going to change direction or just stop.

We also used the "fishbowl protocol" for discussing our thoughts on the subject in between exercises. I scribbled "Fishbowl works" on my notepad during the session... Some ideas I absorbed from the session included:

• Self-organization requires someone to maintain a container within which the team has the power to grow -- to self-organize.
• The problem of negotiation killing ideas due to the effect of multiplying doubt could be alleviated by asking the team why they think they're not acting on the ideas. If asking that question makes the team think about it, it might lead to significant improvements regarding the team's ability to self-organize.

At some point after lunch, Owen Rogers from ThoughtWorks joined us. Laurent also went through a list of literature references related to the topic of self-organizing teams and some of the participants chimed in with their reading lists...

Later on in the afternoon, we moved into serious sports -- a yoga exercise. The idea was to add more complexity into the exercise and see how we can sustain smooth self-organization while following a relatively complex routine (and I'm talking about a real physical routine here!). The vast majority of participants observed significant difficulty in keeping up with the synchronization task while trying to keep up with the routine.

Then we proceeded to the final exercise, which was a theatrical play in teams of 4-5 people. The requirements for the act were that the play was to last for approximately 1 minute, and that it had to include a duel, 20 seconds of silence, seduction, and the phrase "why are the trees all blue?" My team consisted of Rachel Davies, Willem van den Ende, and Owen Rogers. This was actually my favorite exercise in the workshop. It was yet another great example of a simple simulation of escaping the analysis paralysis and simply getting the work done in a high-pressure situation (only 10 minutes to prepare) with no assigned leadership. We're expecting at least two Oscars this year...

The last phase of the workshop was to split into two groups, discuss and identify patterns we've observed in self-organizing teams, and finally presenting the identified patterns to the whole group. This really gave a feeling of accomplishment in the workshop even though it was just a start of a (hopefully very active) discussion in the workshop wiki.

Naturally, we finished the workshop with a round of retrospective questions to identify what to change or improve and what to keep doing.

And, since the sun was shining as a tribute to the XP2004 conference, why not sit down and have a few drinks on the terrace... It's exciting to see the community gather around in such a self-organizing manner!

Joshua was there, Rick Mugridge was there, Diane, Rachel, Jens Ostergaard, Frank, Tammo, etc. etc. Everyone. Except for the Poppendiecks who went missing at some point during the night.

07.06.2004 Workshop: "Customer Collaboration"

I sat down with the Poppendiecks at breakfast, which was nice. It's always so awkward eating alone in a hotel restaurant... Then I headed out to the conference center early to check out whether I could get my laptop online. They're supposed to have a wireless there, but for some reason it didn't work for me. Nico (the conference handy-man) promised to take a look at it tomorrow.

I was really, really troubled with the choice between Marc and Willem's workshop on Systems Thinking, but I had decided to go with Customer Collaboration (lead by Lars Thorup) as that's what I felt closest to the problems I've had in my working environment. Needless to say, after spending some 13 hours with Willem (and a few hours less with Marc) on Sunday, I was starting to have second thoughts about my choice. Now, back at the hotel, I'm again feeling confident about getting more out of Lars' workshop.

Ok. The workshop is now over. This time, the workshop didn't involve physical exercise or sitting on the floor. Instead we started the workshop by (after the mandatory introduction round, of course) splitting into pairs of two to tell a 5-minute story about a past experience where the participant had witnessed either great customer collaboration or poor customer collaboration -- something from which the group might be able to extract useful information. I paired with Helen Sharp, an academic who has observed a number of agile teams in real world projects (Helen is also co-chairing the trainer and educator track during the main conference).

We continued by joining the individual pairs into groups of 4 and repeated our stories to the group one by one. This tended to drive out more details about the stories and to help shape the story by focusing on the essential.

After (and during) each story, the group asked questions and discussed the phenomena observed from the stories. We could see clear patterns emerging from the four stories of Helen Sharp, Angela Martin, William Jones, and your's truly.

The final phase of the workshop was for the groups to pick one story to present to the whole workshop. We chose to present William's story which seemed simple and conveyed most of the aspects we had uncovered from the rest of our stories. The ensuing discussions were at least as fruitful to me as were the discussions of the stories within our group.

Some things I wrote down:

• The Customer/Designer Anti-pattern
  Having the customer, say, ex-DBA express the requirements as the "how" instead of the "what" is a real problem that should be solved a.s.a.p. A good way to do this is to build trust towards the team by making the process completely transparent to the customer.
• The Black Hole Customer Anti-pattern
  The customer withholding important information from the team is a big warning sign and should be addressed as soon as possible.
• The Good Cop, Bad Cop Pattern
  Having an external party bring some amount of chaos and confrontation into the project might be a good thing sometimes – just to get out of status quo and get continuous improvement going.
• The Bridge Pattern
  Sometimes the role of a bridge needs to be fulfilled in order to work around a mismatch between the customer and developer teams.
• Visibility and understanding of the process leads to the trust that is needed for working customer collaboration
• You shouldn't rely on yourself as filling the customer role even if you happen to belong to the demographic of your end-users
• The whole team needs to be educated about a new process upon deployment
• Always ask "why?" when given requirements of which underlying purpose you don't fully understand.
• If you feel like the customer is prioritizing "wrong," try suggesting the use of numeric business value for each feature/story being prioritized
• When a customer sends new requirements or questions via email, walk up to her office and say "let's talk" if at all possible (in addition to answering her question via email, if appropriate).
• It's often best to avoid prejudice by not naming the process you're about to introduce or the techniques you're about to employ.
• A risk-based prioritization is a viable alternative if value-based prioritization does not seem to work for differentiating the stories.
• Always aim to having the customer on-site or have the development team move to the customer.

Oh, and the wireless is still not working although I did manage to get a full-strength signal today around lunch-time…

Oh, and I bought a decent Nikon digital camera from the local optics store. I couldn't help it—the landscape is so beautiful. The camera is otherwise great but it's only 2 mega-pixels (enough for me) and the video recording mode doesn't support audio (which would've been crappy quality anyway).

Alright. I'm off to the conference center again to have something to eat and to chat with the folks.

Interesting. Very interesting. I ringed Brian Hanly and headed out to have dinner with the Exoftware guys (Brian and Sean Hanly, David Putman), William Jones, Mark Kennedy and Mike Roberts. Those guys drink a LOT :) Anyway, it was very revealing to chat with Brian about the business their company is in (enabling agile development versus implementing and outsourcing which is what ThoughtWorks is more focused on). Brian also managed to pay for my drinks and the dinner so now I'm feeling kind of in debt... You guys really should come visit Finland before XP2005 ;)

We ended up on a terrace where Martin Fowler and a group of his ThoughtWorkers had already occupied one table. I tried to take a shot of David putting a lettuce in his mouth with his t-shirt saying "Who ate all the pies?" Hilarious, but I messed it up with the red-eye flash taking longer than the usual operation (I ended up taking a photo of my empty plate).

During the night, we established the fact that "Scrumbag" was already the word of the conference…

I also realized today that I've been deprived of Internet for 60 hours! Argh…

08.06.2004 Conference, Day 1

Great. For some unimaginable reason, the clock in my cellphone had reverted back to Finnish time so I got to the conference center 15 minutes late. Fortunately, Jutta Eckstein was just finishing her welcome speech and about to introduce Ian Hugo who was to give the opening talk about the history of software engineering, starting from the NATO conferences around the software crisis in Garmisch and Rome. I would've enjoyed some more comparisons between back then and right now, though. Ian did try to make a point: solutions lie in management, technology only creates new challenges.

After the keynote speech, it was time for the first paper presentations of the conference under the topic of acceptance testing. Geoff Bache presented a very interesting demonstration of an acceptance testing framework written in Python, which was based on making assertions against a log file. The idea was that instead of recording the actions through a user interface, which makes tests brittle, you would record the actions "behind the scenes" using regular logging statements. A very interesting approach and definitely something worth thinking about.

Rick Mugridge ran through a few slides about test-driving custom Fit fixtures, which was kinda cool but not really too interesting for me since I don't use Fit right now. Jennitta Andrea had two (2) presentations: one about the use of generative acceptance tests for difficult-to-test scenarios, and another about the Canoo WebTest testing framework in general.

My afternoon schedule started with paper presentations under the topic "new insights", which basically meant the "miscellaneous category"...

To start with, John Favaro gave a very interesting presentation about something he calls the Efficient Project theory. The idea was to take the Efficient Markets theory from economics and apply that to software development. In fact, his theory made a lot of sense. I must read his whole paper from the proceedings among the first... Ben Aveling also presented a daring talk titled "XP Lite Considered Harmful", which was bound to cause both laughter and confusion. The point he tried to make was that you should be very careful in doing "XP Lite" and presented a divide between the XP practices which you should use when full XP is not suitable or possible for the particular situation. The other two talks weren't really too insightful.

The program finished with a panel on the topic of "the XP customer", moderated by Joshua. The panelists were Mary Poppendieck, Linda Rising, Angela Martin, David Hussmann, and Chris Matts. The panel was very useful and thought-provoking. Some things discussed during the panel included:

• The customer getting burn-out doing 80hrs/week to do the up-front planning the team had practically delegated to him (lack of coaching was identified as the main contributor to this anti-pattern)
• We should start thinking about our projects as product development in order to get the mental models correct
• Partially done work is inventory in Lean-speak (kind of self-evident from the Poppendiecks' work, but it was so nicely said that I had to write it down...)
• Middle management is the biggest source of resistance to doing XP – the business (top-level management) and the developers are all for iterative and incremental delivery of business value, but the middle management and some (many) project managers can't see how they would fit in into the new way of running software projects, which causes fear and leads to much resistance. Of course, the top management support depends on how they are measured...

I also realized that, for me, the "on-site customer" practice should actually be "full-time customer"...

After the panel, it was time for the welcome reception on the Kurpark terrace and to see the posters which were set up nearby into the main auditorium. There were a couple of interesting posters including one about an XP-focused Eclipse plug-in with a story card editor, and another about Barbara's and Werner's dynamic/adaptive case-based reasoning workflow tool.

Having finished enough glasses of wine, a small group of us decided to go for an ice cream. That small group quickly grew into a horde of almost 20 people, all craving for some ice cream (it had been a very warm day).

Frank had earlier told me a rather suspicious story about a dog "this big". Tammo confirmed Frank's story at the posters, but over the ice cream, Willem finally revealed that it wasn't really that big a dog. Basically just a regular Danish. After the ice creams and some fooling around with digital cameras, we decided to head to the hotels and call it a day.

09.06.2004 Conference, Day 2

The second conference day started with an invited talk by Linda Rising and Mary Lynn Manns who talked about introducing new ideas into an organization. They were basically going through a list of patterns and acted them out on the stage. The patterns included a lot of useful tips such as "tailor your idea to your organization", "don't let the momentum die", and "use the skeptics".

After the coffee break it was time for joining the BOF session on the topic of Return on Investment (ROI), moderated by David Putman. We did the BOF outside in the cafe and continued directly with a lunch. The group included David Putman, Brian Hanly, Karl Scotland, Michael Feathers, Michael Hill, Malte Finsterwalder, Emmanuel Gaillot, Tom and Mary Poppendieck, William Jones and Mark Kennedy, among others whose name I can't remember right now. The things I wrote down of the BOF were basically:

• Talk to the business (CEO/CFO instead of CTO) and focus on benefits and savings
• Try to understand the real reasons for management doing what they're doing

Michael Hill's plenary talk started the afternoon by presenting 10 questions around the topic of transitioning to XP, 5 FAQs (frequently asked questions) and 5 FUNQs (frequently unasked questions), and answering to those from his perspective. He's a very good speaker and threw out some wise words regarding the problems one might have while transitioning, e.g.:

• Saying "help me figuring this out" to the power geek solves a lot of problems
• "Trying is the first step towards failure" was a great quote from Homer Simpson that I really should try to use somewhere (note: that quote is meant to be used as humorous irony)
• "Catch them doing something right" suggests that one should reward good deeds instead of picking on the bad things

After Michael's excellent presentation, it was time for paper presentations on refactoring. The first paper was rather dull, but the second (by Andy Pols and Chris Stevenson) and third (by a fellow from Telenor) were great. The thing I especially liked about Andy's and Chris's presentation was that they actually paired against a chess clock! I simply must try that out... The Telenor guy was also talking about something rather interesting, namely architecting a legacy system away from a dependency hell using an open source tool Telenor has developed named XRadar (http://xradar.sourceforge.net).

The regular part of the conference day was finished with a panel on XP tools, moderated by Joshua. The panel had a slow start. Joshua tried to get some argument going by suggesting that he thinks that IntelliJ IDEA has no chance against Eclipse these days. Unfortunately, there were no IDEA fans present so that died out pretty fast. Eventually things got started and it seemed to me that most of the attention went to acceptance testing tools like Canoo WebTest and Fit. The people that participated the fishbowl included (as far as I can remember) myself, Frank Westphal, Joshua Kerievsky, Rachel Davies, Rick Mugridge, David Hussmann, Mike Roberts, Chris Stevenson, Willem van den Ende, Malte Finsterwalder, one guy from Canoo, and Tammo Freese.

Wednesday was also the night of the social event, which was organized in the concert hall behind the conference center. They had some local dancers and musicians for amusement (yes, amusement -- a special type of entertainment :) and lots and lots of food to munch on. They also handed out beer mugs with the XP2004 label, which was quite nice. I spent a lot of time with Mike Roberts from ThoughtWorks, Sallyann Bryant from the University of Sussex, and of course Frank and Tammo. I also managed to get into a discussion with Erik Lundh about arranging events for a local user group in Finland. Erik has helped ABB, an international giant in electronics and automation, for example, to partially transition into XP and promised to show up as a speaker if we needed one. He also came up with the idea of having the user group meeting take place on a ferry between Finland and Sweden, which might be interesting.

10.06.2004 Conference, Day 3

Ok. Day 3 of the conference and my last day in Garmisch-Partenkirchen. I already have a train ticket to the airport and I know that one can leave his luggage to a room next to reception so that I don't have to carry my stuff around to the conference center. I have 90 minutes before the program starts so I guess I should start packing...

So, the last key note is by two German psychologists named Monika Bobzien and Wolfgang Stark. They're talking about organizational learning. Bobzien is reading directly from the paper and nobody seems to understand the diagram she's trying to explain. Stark, however, was a good performer and managed to get the message through. They talked about three types of learning (single-loop, double-loop, triple-loop) and how you need to juggle between these types to optimize learning when multiple different types of learners are involved. Single-loop learning is basically about doing things right, double-loop learning is about doing the right thing, and the triple-loop learning is about how do you do it.

Stark also discussed the disciplines of organizational learning which are

• Personal Mastery ("what's your purpose in life?")
• Team Learning (learning together)
• Shared Visions (everyone understands what the organization is out to do)
• Mental Models and Dialogue (to be honest, I missed the meaning of this...)
• Systems Thinking (work with the system, not against it, and understand the forces in play within the system)

Stark continued by suggesting that one should balance two sources of learning, namely the past (act-observe-reflect-plan-act) and the future ("sense" the future), which lead to his proposal for the sixth discipline: presencing. Presencing is lead by first uncovering mental models, unlearning, looking around, looking behind the objects, and letting go. The latter part of presencing is about imagining and crystallizing the emerging future, prototyping new praxis, and finally embedding the new praxis into the organization.

After a very unimpressive start, I ended up actually feeling good about the key note (and had written a lot of notes about it as well).

After a coffee break it was time for paper presentations around the vague topic of scalability issues. Angela Martin presented her paper (which won the highly coveted Best Paper of the Conference prize) about how XP met outsourcing. I came out a bit unsure about whether I liked the paper or not.

There was also a presentation about tools supporting Distributed XP (dXP), which wasn't too earth-shaking either although definitely an interesting topic (geeks love tools, don't they?).

After the lunch, however, it was time for Owen Rogers' paper about scaling Continuous Integration. This must've been the one presentation in this conference I would consider the most valuable to myself. Owen had apparently been inspired by the Systems Thinking workshop on Monday because he had rewritten his slides to use a System Thinking-style diagram for describing the problem and the proposed solutions.

In short, the goal we want to achieve is frequent integration and the forces that we need to fight against are More People and More Code. More Code affects positively on Build Time which in turn affects negatively on Integration Frequency. More People affects positively on Broken Builds which in turn affects negatively on Integration Frequency. To solve the More Code problem, Owen suggests that one should consider splitting the build (e.g. into a customer build and a programmer build), deleting code, using mock objects, and doing incremental builds. To solve the More People problem, one should consider splitting the team, making use of a codeline policy, and modularizing the code base. What one shouldn't do is to resort to pre-commit activities such as doing a clean build and running all tests before the commit. Why? Because that would turn every development machine into a continuous integration server! Owen suggests that it's often better to accept that the build can sometimes break -- rely on the CI server to pick up these occasions and exploit the extra speed gained in regular integrations. And I agree. This was a kind of an eye-opener for me, I have to say.

Jutta Eckstein, the head organizer, also presented in this session because someone scheduled for presenting his paper hadn't made it to the conference. Jutta talked about living in a non-agile world, basically repeating the things we had already heard and talked about on the numerous coffee breaks and lunch discussions during the conference.

After the last paper presentations of this year's conference, it was time for the last plenary talk on Crossing the Chasm by Mary Poppendieck.

Mary started by telling an interesting story about the former chief of police, William Bratton, in New York, 1994. Bratton single-handedly turned New York from the most dangerous city of US into the safest one by imposing a set of very disruptive changes in how the police force would do their work. For example, making every senior officer (himself included) take the underground to work every single day made the problems with crime in the underground very apparent to the management and rather quickly lead to real changes. Crime in the New York underground was reduced to almost nothing. What was surprising was that Bratton had done the same miracle 5 times in a row! It wasn't just luck.

The talk was very intriguing and energized the whole audience. Here are some pointers I wrote down:

• Target pragmatists and no one else. I.e. target product companies.
• Market a whole product. People generally don't want to pick & choose.
• Case studies and statistics are more effective than "guru acceptance".
• Differentiate from the competition.
• Give managers cover. Give them an "excuse" to making the leap.
• Chaos is the competition, not the waterfall.
• Changing measurement systems is a key in enabling change.

Mary also mentioned a couple of interesting companies: A Cincinnati financial services company, which had tried CMM, PMO, etc. (all failed) and finally found that restructuring the company into a product organization made the difference and boosted the company's productivity more than anyone could've predicted. GearWorks was also mentioned as an example of a company who transitioned into XP as a desperate attempt for survival. It worked.

Mary also echoed what I had said to many people during the conference: competition creates productivity. The way I see it, not having enough competition to create a sense of urgency is often one of the biggest challenges we have in terms of adopting more productive ways of delivering software to customers.

This year's closing keynote was given by Martin Fowler. He started out with a somewhat weird message of "hating to give talks at conferences"… Regardless of the rather bad start, he managed to turn the talk into a very supportive farewell. Some interesting things I picked up from his short keynote were that it's much more important to actually try new things instead of just talking about them (he had actually voted "no" for every single paper proposal he had gotten for review because they all were saying "someone should try this"), that the product thinking approach proposed by Mary is indeed important, and that "don't do it" is indeed a valid answer sometimes for the classic question of "it hurts if I do this". Martin concluded that we must strive for continuous dissatisfaction and willingness to improve and experiment.

Sigh.

So, the train from Garmisch-Partenkirchen to Munich-Pasing was packed. And most of the passengers were carrying similar black bags with "XP2004" on 'em. I wonder why... It was interesting to hear about Louis Richer's background as an investment banker and a lawyer before jumping to software development.

We -- that is, a car full of conference attendants -- almost jumped off the train on a wrong station after someone mentioned "this is our stop". Luckily I realized that "this doesn't look like the airport" and kept my foot on the door so we could continue our journey without missing our flights. And what a journey it was... I didn't manage to get a direct flight from Munich to Helsinki so I had to resort to a connection through Copenhagen. I was supposed to arrive to Helsinki around 1:30am. Little did I know that someone had it in for me and the connection flight from Copenhagen to Helsinki was full. I ended up flying to Stockholm, Sweden, and spending the night there in the airport hotel and fly to Helsinki in the morning. Nice. I took revenge by attacking the mini-bar since the airline was paying anyway (well, actually the reason for doing that was that there was no place to get food at that late hour and I was really, really starving since I didn't have time to eat anything since the Wiener Schnitzel I'd had for lunch) :)

11.06.2004 Home at last

There's nothing worse than waking up to a hotel wake-up call after a solid 4 hours of sleep. Well, except perhaps the fact that you don't have clean underwear to put on since all your luggage is already in Helsinki...

As if the return trip wouldn't have been enough of a nightmare already, the check-in line was already squiggling around the terminal when I got there (and I thought I was early!). Somehow it wasn't a surprise that the flight was also late...

Anyway, now I'm safely at home and spacing out of all that traveling. Phew. Would I do it again? Of course I would.

Summing it up

It's impossible to express all of what I learned in written words. You have to experience it in order to understand it fully, but I hope some of the things are showing through this diary. I strongly suggest going to such conferences.

Lessons Learned:

1. Leave your Amex home. You won't need it since nobody accepts it.
2. Don't bother with the suit. Dress for sports.
3. Don't count on ever getting to your hotel before midnight.

That's all folks.

In response to Peter Provost's request...

Unit Testing support should be included with all versions of Visual Studio 2005
and not just with Team System.

I just noticed that Clarke Ching has linked some free resources regarding Theory of Constraints. And don't miss the link to a free TOC book on the left-hand side...

If you've been wondering about my whereabouts and total silence regarding the blog, I can explain... I left for XP2004 without telling you. Sorry. The good thing about it is that I'll be soon posting my travel diary when I get home and manage to spill out my brains based on the little notes I've taken :)

The webcast was indeed very good. Jim did a good job presenting the key ideas behind TDD. He used a simplistic example, developing a stack, in his demonstrations but I guess it's the best way to go if you intend to convey the "baby steps" and strict test-first practice to an audience of varying background.

The webcast also clarified a few things for me, including that there will be no unit testing support in Visual Studio before Visual Studio 2005 Team System ships, but there are some "NUnit add-ins" available from 3rd parties. Jim also discussed some different ways of structuring your test code into a separate project/assembly/whatever from your production code or using ifdefs, etc. Unfortunately I missed most of that discussion for certain reasons so I guess I'll have to ask Google when I need to make a decision.

Jim also revealed an interesting detail of his own programming practice -- he starts a task (4-8 hrs of work) with a 15-20min design session during which he enumerates the tests he envisions into a "test list", a block of TODO comments describing the tests in a step-by-step manner, e.g. "push an item to the stack, pop an item, verify they're the same". That's something I haven't personally done, at least most of the time. Thinking back, I have moved very rapidly into writing the actual tests after "getting a visual" as a result of the initial brain activity. I'll have to make a note about trying to create a test list before coding. (Note: obviously Jim's list is not supposed to be final and can/will be appended with new tests found during implementation)

A reminder just popped up from my calendar -- I have scheduled a live webcast regarding Test-Driven Development by Jim Newkirk, the development lead of Microsoft and the author of a couple of XP related books.

While I'm waiting for the webcast to start (in 5 or so minutes, I think), I thought I should mention about it in case someone reading this blog would want to join as well.

If I'm not wrong, this is the first live webcast I've ever attended. Sure, I've downloaded a couple of on-demand webcasts and participated one too many teleconferences but a live webcast is something I've never experienced. I've meant to but since these are typically arranged around 12am US time, it means I have to be at home and online around 8pm, which is a bit fifty-sixty...

Frank Westphal was in town earlier this week so we headed out for a beer after the training course he was hosting. I wish I could've participated this time as well, but I had to do with crashing the party just as they were finishing up :)

My first thought, sticking my head in, was "wow -- this really looks like a team!" You rarely get that feeling from Cubicle Projects talking to each other via email.

The discussions over the beer were also very entertaining, perhaps excluding the neverending nostalgia talk around Emacs and the early phases of Linux... ;)

By the way, anyone going to XP2004 next week?

Read all about it...

Ron has got a point there. His RTS (Running Tested Software) metric is about as close to the purpose of software development as it can get. Practically all other metrics I remember hearing of are either measuring the wrong thing or measuring the wrong way -- in varying degrees. In either case, the result has been some degree of distortion in how people perceive progress.