Day 1
In the end we arrived on time for a Randori session by Dave Nicolette and Rod Coffin. From the moment I learned of this experimental learning session where two people sit in front of a computer and test drive a piece of code while the whole audience is throwing in questions, I was kind of scared of the prospect of being watched while writing code by a hundred people - which is probably kind of normal, given that some people even dislike being watched while pair programming.
The session turned out to be very interesting. One of the key elements of this style of learning is that the audience's energy level stays high for a long time - you have to pay close attention, since due to the random selection of the next person to come to the front you could always be this person. And since you don't want to look like a fool when doing stuff in front of a hundred people (um, what was the problem, again?) my adrenaline level alone was enough to keep me awake.
The other thing I learned from this experience besides a new way to coach technical stuff is that there is a very good reason we do "pair programming" and not "group programming". Throwing two brains at a problem can be a very mighty tool to solve programming tasks, but in some situations throwing a hundred brains onto a very simple programming example felt like sitting in one of Dilbert's most unproductive meetings:
"So we add the game to the character: character.addGame(game)"
"But why don't you add the character to the game?"
"I see duplication, I see duplication!"
"But isn't this, um, less expressive?"
"Duplication is bad!"
"Why do you assign null to a variable, this is done automatically"
After some time of silent observation I realized that sometimes I am exactly like this! So to all of you who have to cope with me on a daily basis: just hit me on the head with a big club from time to time.
The next session was a series of "lightning talks" about all kind of Agile topics where I learned about Alistair Cockburn's Crystal, which is a set of methodologies built upon the Agile principles and an extreme tailoring approach.
Day 2
Despite the enormous amount of a whole liter of "badisches Helles" I had in the evening I was wide awake and ready to suck in new ideas during the conference's main part. The day started with an interesting presentation by Dave Nicolette about how to communicate TDD and design debt to your management. I was particularly stunned by the fact that he did talk about the cost of design debt and the refactoring part in the TDD cycle for a very long time without mentioning the cost of fixing an error in terms of when it is found and the shortened feedback cycles that TDD provides.
The next presentation was titled "why Agile projects fail", but turned out to be about why projects fail in general and provided some insight into the ideas of root cause analysis (5 Why), the dimensions in which failure can occur (The Broken Triangle), and the psychological factors that are the real cause of ineffective development practices.
After lunch the keynote by "Dark Side" Rod Austin from HBS showed how Agile development fits the icy wind of change that swirls today's leading companies in the world from a cost competitive to an innovative business model. After all, who doesn't want a designer trash bin?
Stfan Roock's talk on "Simplicity in Software Projects" was a very entertaining lecture on how easy it is to get so accustomed to complexity that you don't even realize how simple things could be. Well, that and that the Borg are the only entities in the universe who understand that when you travel through space aerodynamics is pointless.
In the end it was very interesting to see big German companies like SAP, EADS and Siemens to take interest in extreme programming. Looks like those ideas are finally going mainstream.
[...] Sass & Veracity wrote an interesting post today!.Here’s a quick excerptXPDays Germany 2007 - Ideas Going Mainstream Nov 25th, 2007 by klimek I had the opportunity to take part in the XPDays Germany last week. The company I work for enabled Uwe, our project lead, Holger and me to participate. It all started with a three and a half hour ride from Munich to Karlsruhe where we heroically overcame a nearly empty tank, a shaking car that felt like it just drank the wrong kind of gas and my own card reading skills - or lack thereof. Day 1 In the end we arrived on t [...]
ReplyDeleteManuel,
ReplyDeleteGood point about the time it takes to fix an error. I'll be sure and mention that next time.
I usually think of TDD as a technique that avoids (most) errors rather than a technique to fix them earlier. Typically, I don't count a defect at all unless it persists beyond the point where the customer accepts a story as "complete." That's probably the reason I didn't think of this point during the discussion.
Cheers,
Dave
Dave,
ReplyDeletethe cost of the error was my main leverage to management until I heard your lecture, as this is equally a benefit of pair programming and TDD. The next time I will add in the refactoring stuff (since we're currently realizing the cost of refactoring in big chunks). This will yield even more exponential graphs ;-)
Cheers,
Manuel
1egor9xpmhq5bqtk
ReplyDeletem88 casino no deposit bonus codes - Sokino
ReplyDeletem88 casino no deposit bonus codes 샌즈카지노 - betway login Try this free mobile casino that accepts m88 ทางเข้า your favorite m88 casino no deposit bonus codes.