My day at #QCon

I spent last Wednesday at QCon. It was definitely an interesting day, but I felt like I missed a lot of stuff on other tracks. I also bumped into a few ex-colleagues from my pre-TW days and an old mate from uni who I hadn’t seen in years – I guess enterprise software is a small world…

First up was Sir Tony Hoare. Not having a background in computer science, I didn’t have quite the same feeling of awe as half the rest of the room. He made a few comparisons between software engineering (pragmatic, seeking dependability, short term view) vs computer science (perfectionist, seeking correctness, long term view), which were largely uncontroversial. Things got a bit interesting towards the end, where he stated his vision: “One day, software will be the most reliable component of every product which contains it … because of the successful interplay of research into the science of programming and the engineering of software”, and then fielded some interesting questions. It emerged that he sees complete specification as the limit of testing. I came away thinking that it’s important to have the computer scientists researching new ways for us to be certain about the behaviour of computer software, and to have the software engineers deciding pragmatically which of those methods are useful, and in what doses. Whether this will ever get us to Sir Tony’s vision, I’m not sure.

I popped into Ola Bini’s introduction to the emerging languages track, to see him explain why languages are important. My highlight here was Ola’s point that it’s all about communication, and we need to consider the best medium (i.e. language) for communicating each part of our systems to the machine, and to other humans. Since the target of our communication changes, so should the medium, and this is why we need different programming languages.

Next up, ThoughtWorks’ Ian Robinson on how to start an SOA initiative at enterprise scale. This was my pick of the day. It was one of those talks that makes you consider a whole new approach to an area of your work. I’ve picked out some key messages.

• We should focus on capabilities which realise outcomes which deliver benefits (the what), rather than on services for services’ sake (the how). This allows us to focus on delivering those capabilities which differentiate our business from our competitors.
• There’s a key difference between who is responsible for a business capability, and who is responsible for keeping a web service up. Engaging those in the first group will help engender a sense of ownership and urgency and ultimately lead us to more value-driven systems. For example, Ian suggests Responsibility Focused Stories (as <role>, I am responsible for <outcome>, which delivers <benefit>) to help identify these people and their responsibilities. From my own recent experience, I can attest that getting these business capability owners involved is often a significant challenge, particularly inside large companies, and I hope to use Ian’s ideas to help me do this.
• Different service implementations are needed for different business capabilities, even if they operate on the same data. Don’t always assume that your business entities will take the same form and live in the same services. In particular the way we use and represent an entity may change significantly over the lifetime of that entity (consider the different capabilities involved in signing up a new customer, and performing daily financial trades on behalf of that customer). Update: see comment from Ian below for a clarification.
• Use consumer-driven contracts to reduce coupling between service providers and consumers.
• Have long-lived capability delivery teams responsible for business capabilities, but augment them with additional resources and knowledge from new projects that are taking advantage of the capabilities.

After lunch I was back in Ola’s track for Jonas Bonér on real-world Scala. He showed a simple chat application using the Lift framework, and whistled through a few of Scala’s more unusual constructs. Overall, I wasn’t convinced by what would make me choose Scala over any other functional programming language – it largely resembled Java with a few extra constructs thrown in. I think Jonas missed an opportunity to demonstrate the practical benefits that these constructs could bring and so get people excited it.

I then decided to go to Michael Feathers and Steve Freeman talk about the history of TDD. Having written and co-written Working Effectively with Legacy Code and Mock Roles, Not Objects respectively, I have a lot of respect for these guys.  Those texts played key roles in my understanding of good OO design. The session was an interesting history lesson, a useful reminder of the core principles, and contained a few nice anecdotes. I was particularly tickled by the fact that early practitioners of testing (Gerry Weinberg, Kent Beck) just assumed that everyone else was doing testing too, as they considered it to be part of doing a professional job. Plus ça change.

Martin Fowler then described our experiences with Ruby projects at ThoughtWorks over the last few years. It was good to see some statistics backing up the idea that Ruby works in the enterprise. 36 of the 41 projects ThoughtWorks has undertaken in Ruby would use it again, and of those 5 that wouldn’t, 4 said that the reason was due to the problems getting people to adapt to Ruby, rather than Ruby’s ability to perform the job required. An amusing anecdote midway through: developers on a Ruby project estimated their productivity boost (over, say, Java) as 2-5x in earlier parts of the project, reducing to 1.5x in later parts, but jumping back up to 2-3x when they had to go back to Java and remembered just how bad it was! Martin’s a great speaker, so as always it was an entertaining session.

In conclusion, I enjoyed all the sessions and heard some interesting things. But the biggest lesson I’ll take away is to go to talks about things I don’t know about, not things I do. I’m sure I’d have learnt a lot more new ideas in Rich Hickey’s Clojure presentation than in Michael and Steve’s TDD history. Not through any fault of Michael and Steve (and I certainly don’t want to pick on them), but because I’ve read a lot of that stuff before. There were also a number of talks on web architecture and RESTful services that I’d like to have caught. I also wish I’d taken notes in more of the sessions; as well as helping me take more of the information on board it would have helped me writing this post!

For those who couldn’t make it (and others like me who want to catch up on sessions they missed), all of the slides are on the QCon site, although some may need an attendee-only password.