Today (Friday, October 24, 2008) was the final day of Colorado Software Summit 2008. As usual, the last day is really half a day with two morning presentations before lunch. My last presentation was in the first slot and I spoke on Java Management Extensions (JMX) Circa 2008 for the third and final time at this conference. After that, I had the privilege of attending Simon Roberts's presentation What OO Doesn't Address. In this blog entry, I'll discuss some highlights from Simon's presentation and then conclude with some thoughts on the overall week-long conference.
Simon Roberts - What OO Doesn't Address
For the last session of this conference, I did not think I could look at another line of code this week and I had heard good things about Simon's presentation (an advantage of having every presentation offered three times each is that you can change your plans to attend something with such positive buzz). Because of this, I attended Simon's presentation. Simon addressed why we, the software development community, largely migrated to using object oriented principles and languages. He talked about the many things such an approach addresses as well as some of the areas in which it only partially addresses or does not address at all the problems we face in software development. This was a nice presentation to end with because it validated many of my own conclusions from years of object-oriented software development experience and added some new ideas for me to think about. His presentation also helped me to recognize more completely where object-oriented approaches help and cannot help deal with development problems.
While there were several aspects of Simon's talk I could focus on, the two things that I will point out here was his reference to R. A. Heinlein's Stranger in a Strange Land (1961) and his coverage of the "Duck Poop Test." Simon referenced Strangers in a Strange Land because it brings up the concept of groks, beings that become so familiar with the surroundings that they actually become part of what they are observing. He stated that developers approach this type of relationship with their code.
I especially liked Simon's reference to the "Duck Poop Test." I was already familiar with the concept of the Duck Test (it is sounds like a duck, walks like a duck, quacks like a duck, it probably is a duck). This is commonly used to describe Ruby's (and other dynamic languages') treatment of dynamically typed variables. Simon used it to illustrate that an object is what we want it to be (such as a duck) if it implements all the behaviors and characteristics necessary for that object (duck). The "Duck Poop Test" involves situations when the object doesn't behave as we expected (designed). How do we handle it when we see this duck poop on the ground? Do we try to work around it or do we fail fast? Simon used the duck poop test is fairly graphical detail and made some motions and quacking sounds for a duck gone insane. It was highly entertaining and, more importantly, got the point across. We need to be very careful about we handle the duck poop (failed assertions and exceptions that occur that break what we designed our object for).
Colorado Software Summit 2008 Overall
This was my fourth time attending after previously attending in 2002, 2003, and 2004. This year's edition was every bit as enlightening, entertaining, stimulating, and tiring as in previous years. By Friday, I have so many things going around in my head and have so many new things I want to try out, that I am eager to go and get started. However, at the same time, absorbing so much in such a short period of time is exhausting.
I learned a few things about the Colorado Software Summit by being a presenter. In the past, as an attendee, I knew of the high quality of the speakers at this conference. However, as a presenter this year, I observed much more closely this year the high-quality (in terms of professionalism, skillsets, experience, and behavior) of the conference attendees. In just about every one of my presentations, I talked to one or more developers who have been using the technologies I was discussing and had applied these technologies in ways that had never occurred to me. I may even blog in the future about some of the ideas that attendees pointed out.
Another lesson I learned more completely as a presenter is the amount of error that presenters put into their conference presentations. I spent significant hours on my two presentations and then the two 90-minute presentations offered three times each mean that the speaker ends up talking for 9 hours in the 4 1/2 day period. There are little things to deal with as a speaker such as remembering what you have said in this session versus a previous session and constantly tweaking slides and examples through the week based on attendee feedback.
It was a great honor to be able to speak at Colorado Software Symposium 2008. While it has been exhausting and extremely time-consuming, it has been equally rewarding. I have learned so much about Flex, OpenLaszlo, and JMX in preparing for the talks and in talking to other users of these technologies. I have enjoyed hearing about people who were looking for an answer to a particular problem and have now found that answer in Flex, OpenLaszlo, or JMX. I have also learned so much about the wide variety of technologies covered here and want to go apply some of those technologies to problems I need to resolve.
The dates for Colorado Software Summit 2009 are October 25-30, 2009. It will be here before we know it.