Java Posse Roundup 2009 Summary
Posted on 10. Mar, 2009 by todd in Java
I spent the week of March 2 – 6 in Crested Butte CO. at the Java Posse Roundup. I’ve had the great fortune to have been to the previous two Roundups. It’s a very inspiring week. The Roundup is organized as an Open Space style conference. This style of conference is quite different than a typical ‘eyes forward’ conference. It’s self organizing. By that I mean that a general topic is suggested by the organizers and then on day one, participants choose specific topics. Topics are frequently merged, shuffled around and put into time slots. Participants find a topic they are interested in and the conversation begins.
This is the biggest difference between this style of conference and a ‘regular’ conference. There are no lectures, no power point slides. There is just conversation. And it’s awesome.
The topic of this year’s conference was Developer Productivity on the JVM
Day 0 – Alternative Languages
This year we started a day earlier than we have in previous years. There are a number of participants that in addition to writing Java code on the JVM, they write apps in other languages. Groups that were interested in other languages on the JVM self organized and started Coding Dojos. This was a new concept for me and was curious to see how the process worked. We hosted a Grails (Groovy Web Framework) application. This was the first time that any of us had spent any amount of time implementing a Grails application. It was fun, but it was a little bit of the blind leading the blind and it would have been great if there was someone in the coding dojo that was a Grails expert, or at least had some experience that the rest of us could have learned from. Regardless, it was great to spend a few hours just hacking and experimenting with the framework.
In the afternoon I hung out with a bunch of folks that were interested in the Fan programming language.Fred Simon has been helping out the authors of the Fan language. He’s been working on a plugin for IntelliJ’s IDEA to support Fan. Fan looks like an interesting language. At a very high level, I would say Fan looks a lot like Groovy with the primary difference being that it is statically typed. The other big feature of Fan is that in addition to being a JVM language it also runs on the Microsoft CLR. It’s pretty early days for the language but it does look interesting.
Day 1
The first session I participated in was Scalability. Its a topic that I’ve been interested in for a while and it’s always interesting to see what other folks are doing in this realm. There is some very cool stuff going on with Amazon’s Elastic Cloud Computing (EC2). It’s not really an architecture we can leverage but it is interesting to hear about what is going on in the grid computing space. What was helpful was a conversation with my friend Ido. He and his team are doing some very cool stuff at High Gear Media. The conversation centered around various caching strategies including memcached and Teracotta.
Second Session was a conversation on technical debt. This is a topic I had heard about but really wasn’t that familiar with. The basic premise is that each time we take a shortcut in developing a solution we incur technical debt. This debt needs to be ‘paid back’ at some point in the future. We’ve all been under pressure to implement a solution quickly and know full well that the solution we’ve completed isn’t the best. We may not know enough about the requirement at hand or perhaps are forced to use a framework/technology that we know from the start is wrong. Typically, these debts are hidden in the project and if they are addressed, they may get lumped in with other development. Sometimes they don’t get done because they are effectively hidden from everyone except for the development team. One good idea that came from the session was to raise a special kind of ‘defect’ in your bug tracking system when the debt is first detected. That way it becomes visible to everyone in the project. It doesn’t necessarily mean that it will be addressed in the short term but at least it’s not hidden. Another way of raising the profile of the technical debt issue is to relate new bugs that are caused by the technical debt. Once a number of high profile bugs can be proven to be as a result of the original issue it will give the team more leeway for convincing the product backlog owner that time needs to be spent on the debt. Good ideas.
Day 2
First session today was developer communication. There were lots of good ideas including a number of books that folks suggested. Tom DeMarco’s Peopleware is one that I have on my bookshelf but have yet to read. Barry suggested anything by Mike Cohn and specifically User Stories Applied: For Agile Software Development. Another book that I’ve been meaning to read is Secrets of the Rock Star Programmers as well, daily standup meetings were ascribed to be one of the best ways to increase communication on the team.
The second session had the great title of “You got Peanut Butter in my Chocolate. Multiple Languages in one project”. It’s generally accepted that most projects these days have multiple languages. They include build languages, markup languages, scripting languages and “formal” languages (Java, C, Scala, Groovy etc.). Multiple people on a project should be familiar with the languages used.
Day 3
The first two sessions were related to Design. Again, like many of the previous sessions the key is communication (very much a recurring theme). Design happens regardless and the more conscious we are about it the better the outcome. Design either through a formal design process or an informal implementation/coding session are equally important. Take time for designs to gel. Don’t get too attached to designs, let them evolve. A couple of good resources on this topic include the book Don’t Make Me Think, Tufte’s The Visual Display of Quantitative Information and anything by Kathy Seieria. Encourage metaphors in design but don’t get too attached to them. Bad metaphors can do much more harm than good. Good design is both simple and elegant. A comment was made that the design process isn’t necessarily agile. I’m not sure about that but at some level that has been my experience. Maybe incremental design isn’t the ‘best’ way. I’m still mulling that over in my brain.
Joe Darcy from Sun convened the Small Language Changes discussion. He is responsible for Project Coin for JDK 7. He did a quick overview of what is planned for JDK 7 (nothing is cast in stone yet) with a delivery date in 2010 (Java One would be my guess). The big piece of development for JDK7 is the new module system. This lays the groundwork for future enhancements to the platform and provides the technology for finally replacing old bits of the platform with new shiny bits. This is a very core platform change that will take a lot of engineering skills to pull it off. The balance of the changes for the platform/libraries are mostly smaller in nature. His project is to move the language along in a few small incremental ways. There is a process for anyone to suggest language changes. It sounds like a very formal process and one that appears to have the bases covered. There are a few things like streamlined generics declarations such that List<Foo> bar = new ArrayList<Foo>() would be replaced with something like List bar = new ArrayList<Foo>() which is a good small change and something that should have been the original implementation in my opinion. There may be simple list and map accessors (like those found in groovy/ruby). Perhaps an update to JavaDoc and others.
Day 4
Designing APIs
When developing APIs, unit tests should be built in parallel to exercise the APIs. Pair programming is another very effective way to work through APIs. It most likely has to do with one person thinking about the problem while the other is working on it. Like most things, having someone else test the APIs works much better as usability/flow issues will be more apparent. Make the important things easy and the rest possible. One idea is to have an ‘expert’ mode in the API that could be turned on when the user is comfortable. A few ideas were thrown out that the API could be marked up with annotations to help tools drive things like code completion and javadoc for the advanced usages. It was also suggested that for a large refactoring that the API designer/implementer provide some sort of migration path/tool for users of the APIs.
Career Path
Dianne kicked off a discussion about the technical career path and how it’s very hard to balance management and development. Joe made the observation that one reason that developers find it hard to do management is that the opportunities to get into that flow state in management are few and far between. Management tends to be more interrupt driven and therefore not conducive to that flow state. We discussed the idea that success for management is measured as team success and that management gives folks an opportunity to have more control and overall impact. It was generally agreed upon that coding was more fun but that management while important, is not for everyone.
Testing
The last sessions was a conversation about testing. Like many discussions about testing, the lines were blurred between what was ‘unit’ testing vs. ‘integration’ testing. We talked through some tools and approaches. For web testing, it sounds like Selenium is a good choice (for robot style exercise my site type of testing). Someone suggested that Splunk is a good tool for doing log file analysis.
Summary
It was a great week. I met a lot of very smart folks who are very passionate about the art and science of software development. Every year the fellows have the roundup, I’ll be there. It’s a great week and if you have a chance to come, you should.