NFJS Milwaukee 2009: Reflections and Highlights

What a great conference! I feel humbled by the depth of experience the presenters showed. And the quality of their presentations was outstanding. I'm very grateful for all the wisdom and tips they shared. There were two presenters in particular that stood out for me: David Hussman and Stuart Halloway.

David Hussman started his Architecture and Agility are not Mutually Exclusive talk with a slide that showed a picture he took in Cairo. It was an urban setting with a 20-story ramshackle concrete building in the foreground. It had several big satellite dishes on it, scattered across various stories. In the background you could see the pyramids of Giza. The rest of the talk was deep and relevant thinking about the importance of architecture and agility.

One thing he said that really crystallized some things for me was that the necessity for agility is really best understood by considering this: Suppose you fully understood the requirements (of some system) and this understanding is a perfect reflection of reality. And then you begin to build. At some point, the needs and requirements may change. I'd always focused on this (based on my own experience) as changes in understanding. With the implicit assumption that this was a fault in our ability to communicate or understand requirements. It's not that that doesn't happen. But Hussman's way of stating it was much more profound.

We need to be agile because the requirements themselves change. The features that matter change. This is not merely that our understanding of some unchanging feature set changes. Or our ability to communicate and understand some unchanging feature set changes. It's that the features and pressures and opportunities themselves are changing. And we need to adapt to that.

I spent all day on Sunday attending Stuart Halloway's talks. The morning was focused on agility, tactics and strategy. The afternoon was focused on the next generation of languages running on the JVM, ending with clojure (a functional lisp-like language).

I think what I appreciated most about Stuart is the obvious depth of experience he had in implementing agile methods. And what conveyed this the most was all the mistakes he shared and how he learned to adapt and change based on them.

For the afternoon, he started with a refactoring of some Struts Java code. He went through about a 10 step refactoring that took something that was originally about 15 lines of code in a single method down to two one-line methods in idiomatic Ruby. It was incredibly powerful.

One thing he said that I'd like to write more about was that it's professionally irresponsible to write code in Java. I'll save that topic for another day.