Developers - do you go to conferences?

Last week I attended QCon London, a conference focused on enterprise development and which spans multiple technologies, including Java, .NET, open source, database, mobile, and general development methodologies.

It is among my favourite conferences thanks to its vendor neutrality and the high quality of the speakers and attendees it attracts. Nevertheless, only a tiny fraction of developers make it to QCon. Vendor events like Microsoft TechEd or Oracle OpenWorld/JavaOne are bigger, and great for keeping up with what that vendor is up to, but tend to be less though-provoking as the content is steered by what one company wants to promote. It still seems to be only a small minority of developers that make it to such events.

There are lots of reasons for staying away: they are too expensive, or your company will not make the time available, or you are not convinced that there is enough signal above the noise, or you are too busy simply keeping up with the work you have already. Are conferences an unnecessary and costly distraction?

My view is the opposite. Of course I am a journalist and it is my job to track what is new; but I do some development as well, and feel that there is a real risk of falling into a safe pattern of work that makes us blind to new ideas that can quickly repay in productivity or quality the time spent in learning about them.

It is also remarkable how a good event can recover enthusiasm for the craft of writing software, something easily lost in the humdrum world of requirements and deadlines and sometimes dysfunctional corporate structures.

As for QCon, there were several things I came away with - though bear in mind that there were six tracks, so one person could only attend one sixth of what was on offer, keynotes aside.

I spent some time on the mobile track. A session by Fraser Spiers on the Apple iPad in education was irritatingly Apple-centric, but also stimulating in showing how a new model of computing can bring about profound and beneficial changes. I think we will see a lot of iPads in business computing too.

Jerome Dochez spoke on the future of Java EE, not the most exciting session but helpful to see how Java is embracing the cloud computing model.

Google's Patrick Copeland spoke on innovation at Google, with the underlying question being how to create a culture that is friendly rather than hostile to innovators and their ideas.

At the .NET State of the Art track I learned about creating RESTful services, both with the open source OpenRasta and with the official WCF Web APIs; I had not been paying attention to this area and it was an example of how attending a conference can highlight existing and important developments that you might otherwise miss. Of course being QCon the speakers were OpenRasta's author Sebastien Lambla and on WCF Microsoft's Glenn Block; exactly the people you would want to hear on these subjects.

On the last day at QCon I got best value from the NoSQL track. A simple example in a talk on graph databases and Neo4j, where the database needed to model social connections and answer questions like "Who are this persons friends, and the friends of his friends", convinced me that SQL relational databases are not the answer to every kind of data storage problem. Note that NoSQL stands for "Not only SQL" rather than "Never SQL"; you should choose the right data store for what you are storing.

The Guardian's Matt Wall described how the Guardian web site is migrating from Oracle to mongoDB, giving the rationale and describing the benefits. I had never looked at mongoDB before and it was a fascinating talk.

At a high level, QCon has its roots in Agile development methodology; and if you study this you find that much of it boils down to fostering communication between all of a project's stakeholders (not just developers). If you came away with one good idea for improving communication in your own organisation, the whole event may well have been worthwhile.

It does not have to be QCon. My point is that going out, talking to your peers, and getting this kind of input is enormously worthwhile, even in busy or economically testing times.