Prior CITCON experience posts:
Briefly about the conference - the open space format is still the best thing since sliced bread as far conferences go, and CITCON still brings together wonderfully smart people. Year after year I leave it being thankful for pointing me to questions (and answers) waaay outside the proverbial box....
Are we doing improvement wrong? Proposed by Jeffrey, inspired by the Toyota Kata book, it described the two Katas, and illustrated why measuring improvement by the output (results) only can lead to missed improvement opportunities (e.g.: the book describes that before an improvement effort, line managers were called in for troubleshooting 1000 times a shift, which then decreases two 700 a shift. The leadership's response was that this means either
- people are hiding or working around failures, which is bad
- people stopped improving, which is bad too
so they adjusted the workload to enable taking full advantage of the bandwidth of 1000 improvements/introspections the factory was capable of.
Continuous interruptions Proposed by Kishen, we dug deep into how interruptions can be a wonderful tool for knowledge sharing, mentoring and how they hide (or to be more precise, expose) risk factors. I wish I had mentioned the urban legend about the QWERTY keyboard layout's design origin, but the point about interruptions slowing you down enough to force taking a step back didn't need analogies. And it seems we all have colleagues whose cell phones only ring when their owners, unlike the phones, are not present...
What does the ideal software development process look like? proposed by Andrew Parker, closely linked to the first session of the day about improvement (towards the ideal one to one flow) is probably the one session that I left with more questions than answers - not just about the topic, or its conclusions (shorten the cycle time (effort) required for going from idea to getting feedback), but even about the open spaces framework (what if the scribe wants to apply the law of two feet?).
Low level unit testing/assertion code patterns proposed by me, driven by my desire to learn what new ideas are present in this space. While I haven't learned of any new patterns, I left with a much better understanding of how language embedded and enforced pre- and post-conditions (or code contracts in the C# world) can actually been tested, contrary to my initial assumption
Are we testing too much? / What's the point of code coverage? / Would a Test Tree Builder and Executor make sense? - this was a merge of three topics, proposed by Kishen, Arjan, and myself. It was the smallest session in attendance (it was the three of us and Cirilo, with Jeffrey also popping by towards the end), but true to the spirit of open spaces, we were totally engaged. Plus Jeffrey demonstrated the need for more effectively transmitting information (when we brought him up to speed of what is being discussed, he just said "CITCON Australia 2009") or prior art - there is a kind of generational gap that exists between programmer generations that could benefit from a few more bridges (though leaving enough of a divide so that people will still work on and solve problems that were previously declared "unsolvable"!).
Had I not proposed any sessions, I would have loved to attend Steve
Freeman's TDD Clinic - it's always a pleasure to see great
people perform, not to mention the learning opportunity. I also would
have liked to listen to Ivan Moore describing the build setup
they have for their multi componented system at work - I faced that
problem years ago, topped with the plugin compatibility across multiple
versions problem, so would have loved to see what they did. And next
time I'm in Budapest, I'll probably try to visit Prezi again
in case Jayson is around so I could take another look at their
system (and to listen to the
provisioning evolution story again). Luckily, Zejko's
session's about how Wikipedia tests there system is easy to
find online, since - like everything else Wikipedia does -,
it is open. But as I always say, it's so much better to leave a conf
with too many good sessions than one with too little...
Another great aspect of CITCON is the dinner afterwards - even though it splits into multiple small groups, it's real nice to talk with people directly, both about non-tech (like explaining why it would make a ton of sense for the Budapest Opera House to organize a summer Opera festival) and tech (thanks to all who listened to my pet project ideas, and gave really useful feedback!)
The reunion-like feeling PJ mentioned during his opening remarks was true for me too, but sadly I haven't prepared enough - I should have organized more explicit catch-up sessions outside the conference, for I couldn't chat with everyone I wanted to in enough depth - hard to do when we are running additional sessions even during the lunch break! Plus of course one doesn't want to give the conference itself an exclusive atmosphere - I still vividly remember my nervousness at my first CITCON, trying to overcome the inherent shyness to talk to people, attempting to join their conversations...
In closing, I would like to thank Marco Abis again, who was the remote-local organizer of the conference, for making it happen. I met wonderful new people, and learned (or refined my understanding) of many topics!
During the coming days, I will be adding my session notes to the conf wiki coming days, and once I digested all the feedback I got during and outside the sessions, I will be writing up the Tree Optimized Test Runner and the app-test DSLs to have multiple drivers for a single TestCase ideas in more detail.