QCon day 1

A lot of good stuff today, but I’m just going to jot down a couple of my favourite points:

Craig Larman talked about massive-scale Scrum-based projects. I don’t suppose I’m going
to be running (or even part of) at 1500-person dev team very much, but some of his points
are applicable at any scale:

• The only job title on the team is “Team Member”. There might be people with specialist skills,
  but no-one can say “it’s not my job to fix that”
• If you don’t align your dev. teams’ organisation with your customers, then Conway’s law means your
  architecture will not align with your customers either, and you won’t be able to react when their needs
  change
• Don’t have management-led tranfoormation projects. How will you know when they’re done? Instead,
  management’s role is just to remove impediments that the dev team runs up against – the “servant-leader”
  model

Dan North spoke about how he moved from what he thought was a pretty cutting edge, agile environment
Thoughtworks, consulting to large organisations starting to become leaner/more agile) to a really agile
environment (DRW, releasing trading software 10s of times per day), and how if you have a team that
is technically strong, empowered, and embedded in the domain (i.e. really close to the users), you can do
away with many of the traditional rules of Agile. A couple that really struck me were:

• Assume your code has a half-life. Don’t be afraid to just rewrite it, or bin it The stuff that stays in
  can get better over time, but it doesn’t have to be perfect from day 1
• Don’t get emotionally attached to the software you create. Get attached to the capabilities you enable
  for your users
• Remeber, anything is better than nothing.

Juergen Hoeller talked about what’s new in Spring 3.1. No amazing surprises here, but some nice stuff:

• Environment-specific beans – avoid having to munge together different config files for system-test vs.
  pre-production vs. live, have a single context with everything defined in it (Even nicer, arguably, when you
  do it via Java Config and the @environment annotation)
• c: namespace for constructor args. Tasty syntactic sugar for your XML, and the hackery they had to go through
  to get it to work is impressive (and explains why it wasn’t there from the start)
• @cacheable annotation, with bindings for EHCache and GemFire (not for memcached yet, which is a bit of a surprise)

Liz Keogh talked about perverse incentives. Any time you have a gap between the perceived value that a metric
measures, and the actual value that you want to create, you make an environment where arbitrage can occur. People can’t
help but take advantage of the gap, even when they know at some level that they’re doing the “wrong thing”.

• Focus on the best-performing parts of the organisation as well as the worst-performing. Don’t just say “This
  project failed; what went wrong”; make sure you also say “This project succeeded better than all the others; what went right?”
• Don’t try and create solutions to organisation problems, or you’ll inevitably make perverse incentives. Instead, make
  make Systems (Systems-thinking, not computer programs) that allow those solutions to arise.

Chris Read and Dan North talked about Agile operations. Surprisingly for me, there wasn’t a great deal of novel stuff
here, but there were a couple of interesting points:

• Apply an XP-ish approach to your organisational/process issues: Pick the single biggest drag on you delivering value and
  do the simplest thing to fix it. Then iterate.
• Fast, reliable deploys are a big force multiplier for development. If you can deploy really fast, with low risk,
  then you’ll do it more often, get feedback faster, allow more experimentation, and generally waste less. The stuff that Dan
  and Chris work on (trading data) gets deployed straight from dev workstations to production in seconds; automated testing
  happens post-deploy

Yoav Landman talked about Module repositories. Alas, this was not the session I had hoped for; I was hoping for some
takeaways that we could apply to make our own build processes better, but this was really just a big plug for Artifactory,
which looks quite nice but really seems to solve a bunch of problems that I don’t run into on a daily basis. I’ve never needed
to care about providing fine-grained LDAP authorisation to our binary repo, nor to track exactly which version of hibernate was
used to build my app 2 years ago. The one problem I do have in this space (find every app which uses httpclient v3.0,
upgrade, and test it) is made somewhat easier by a tool like Artifactory, but that problem very rarely crops up, so it
doesn’t seem worth the effort of installing a repo manager to solve it. Also it doesn’t integrate with any SCM except Subversion,
which makes it pretty useless for us.

Chris May : 10 Mar 2011 08:09 |  Tags: Qcon2011 |  Comments (0) |  Report a problem