QCon London 2012 Retrospective/Post-mortem

Intro
This was my second visit to QCon London. My impression of the conference, based on these two visits, is that it tries to focus more on the bigger issues such as architecture and management, and less on coding details (although present). An example would be that a dedicated .net track wasn't present, despite the platform's popularity. øredev, which I've visited basically every year, does the opposite and focuses more on hands-on coding, but let this be about QCon.

I didn't really learn anything new at the conference, but was rather strengthened in what I've come to hold valuable regarding sustainable, high quality software development over the years (due to experience, theory, or both). I had the opportunity to chat with some of the speakers, since QCon is organized with social events to facilitate that, and was even further convinced by that.


Architecture
One big trend was splitting up larger applications and web sites in "systems of systems" and software architecture on both micro and macro levels. The latter being between smaller systems, hence more stable and important, while the inner workings of the smaller systems is of much less importance.

"What's simpler than one thing? Two!" meaning that small systems are much easier to modify than large.

Michael Brunton-Spall gave a talk named Architecting for Failure, where he described how The Guardian had re-architectured their whole web site from a huge monolith, into a lot of smaller systems. The only thing they had standardized on, was the JVM. Not only are they more robust and flexible nowadays, but innovation has increased a lot due to the change. Now they code, release, and test small bits in isolation.

So why is it then, that we're stuck with large monolithic applications, that are hard to modify? The main objectives change over time. First, we value things like ease of development, homogeneity, cohesion (one big sln-file to rule them all) and simplicity. Over time we come to value things like heterogeneity, decoupling, modularity and autonomy.

In one talk it was said that there's always a lot of management reasons to not change the architecture from the former to the latter, despite it being a good idea. I guess it's easier to identify the risks, than the opportunities that comes thereof.


Software Engineering
Since I'm a big fan of GOOS, and working in a need-driven fashion, it was great to listen to Steve Freeman et.al., describing a team delivering high quality software every second week for seven consequitive years. How? Using most practices from XP and making sure every feature has executable acceptance tests (or specification by example, as it's commonly called these days due to Gojko Adzic's book) and time isn't more important than getting the requirements right. Last, but not the least, the team made sure that new hires not only had high technical qualifications, but also shared the same mindset in order to fit in the culture.

Since they pair-program 100% of the code, turnover hasn't affected the speed of the team. Conclusion of XP and NDD according to them: cheap and reliable.

I think Rob Bowley summarized it great, with the quote "It’s the code, stupid". He went on with details on the subject, but this one stands out: "clean, maintainable, well tested code [is] more important than anything else you do". One can read his notes from the talk for more info.


Testing
Context is king. Great results seem to come from teams doing SBE and TDD. However, if you're a part of the tiny fraction of the software industry creating services like social networks and games, and the like, where the service is free or very cheap, and the impact of bugs isn't that big; you can let the end users test your software for you (logs, feedback links, forums, etc.) in order to produce the software faster and cheaper.

This also addresses the biggest problem these services have; what's the right product? When working with SBE in a traditional setting, the pre-requisit is, that you via specification workshops, domain experts, or something else can capture pretty much exactly what you're supposed to develop. If this simply isn't possible, you have to let your user-base guide you.


Management
In his talk Agile Adoption is Fool's Gold (and other stories from the coal face), Rob Bowley said what we've known for years: SCRUM == training wheels, while you're better off with Kanban, when you're mature enough (you can't go there directly).

DevOps? Yes! Dan North told a great story about how they had managed developers and operations personal to work together, and how beneficial that had been. So much low hanging fruit!

Jodi Moran took it one step further, and said "operations is dead" which was clarified with "When all engineers operate the system, the constraints and requirements of the operational environment will always be taken into account", and two other statements.

If you want to change anything, telling people what to do will most likely fail. Make them want to go where you want them to. How? Prove that it makes sense. Pair program. Action! "A little less conversation a little more action"

Zach Holman's talk How GitHub Works was very inspirational, despite that I've read all about it before. Zach is a very professional coder and speaker, who backs his story with real success. He basically tells the story of a programmer's heaven. No meetings. At. All. No managers (they distract). No estimates and deadlines. No time keeping. At. All. ("Hours are BS!", "Creating code is a crative endeavor!", "Embrace flexibility!", "Working long hours isn't a badge of honor!" and "Marathons drains you mentally == shit code!") Family-friendly. Everything is optimized for happiness :-) We want the best work, and get it when people are happy. (BTW, check out the RSAnimate about why that's a great idea.) 8000 tests in 250 seconds (slow test considered regression). Pair program scary code, and with new hires. Only hire really good people. The list goes on... and it feels good to be an enterprise customer of GitHub.

Everybody talking on the subject of management emphasized the importance of hiring only the best people. I wholeheartedly agree, but I've never hired someone with money from my own pocket, so I haven't really put my money where my mouth is on this one... If the theory and evidence on this subject shows great results, why isn't it done more often? I've even had a boss, who said "we don't need good developers here"... If you're interested in the subject, Why Zuckerberg Is (Almost) Right About Great Talent is a good article IMHO.

In another talk, Dan North talked about how every decision is a trade-off, and concluded that "there are no best-practices". Context is king.


London by Night
A big <3 to my colleagues, with whom I spent some really fun London nights with!