20 Dec 2012 YOW! 2012 Melbourne: A Conference Report
YOW! 2012 took place a few weeks ago, bringing some of the world’s best developers and agile gurus on a roadshow across Melbourne, Brisbane and Sydney. Having been to YOW! in 2010 and followed the line-up last year, I can say the conference undoubtedly continues to improve each year. In this blog I will talk about my overall impressions of the conference, and a couple of the more interesting things that stood out to me. The organisers continued with the same venue as last year, the Siebel in Albert Park. The high ceilings and elaborate chandeliers at the Siebel give the conference a more professional feel than YOW! 2010 had – even if most devs are still just wearing t-shirts! The conference rooms also have plenty more seats and a larger/raised projector, meaning you no longer have to look over anyone’s head to see the slides.
The organisers seem willing to tinker with the format. To me, the speakers seem to have moved from a full list of book-authors (eg Eric Evans, Martin Fowler) to a wider thought-leader group – ‘rock-stars-in-the-making’, if you will – from successful and innovative companies like Netflix, Groupon and Heroku.
That said, the organisers know what not to change, so old favourites remained. Legends such as Eric ‘I Eat Co-Monads for Breakfast’ Meijer and Mike ‘Worlds Toughest Programmer’ Lee have continued along for the ride by presenting some thought-provoking keynotes.
The ideas presented at YOW! can both challenge current conventions or confirm things you’ve been thinking to yourself for a while. Let’s dive into two things that advanced my thinking on software development.
Success, Failure and Entropy
Mike Lee – the self-proclaimed ‘worlds toughest programmer’ – talked about what he called ‘the most important minute of your life’. In doing so, he did something I’ve not seen a developer do before: bring philosophy to a room of other software developers.
Having studied some philosophy myself, it was great to see him riff on some philosophical themes that the audience wouldn’t be accustomed to hearing. It was a very brave and deeply personal feat, and whilst it may not have hit the mark with everyone, it was still impressive that he gave it a go.
The most memorable themes from his talk concerned perceiving life, and doing what needs to be done when a decision of whether to act or not must be made. As he put it, failure and success are the same thing, only differing in how we perceive them and how differently we behave when we experience each one.
Experiencing failure means you have to do something about the failure now, whereas you can have successful people who are just lucky, and in other scenarios would fail just the same – if not more spectacularly – than those who have had to face their failure. In this context, the ‘most important minute’ concerns being able to focus regardless of whether you are experiencing success or failure.
Lee also cited something that Apple do: maintaining a role on a project team that is occupied by somebody who wasn’t an original member of the team, but are nevertheless responsible that the project gets done successfully. To make matters worse, the person in this role has no official authority, meaning that in order to get things done, they have to actually talk to people.
The reason Apple do this concerns entropy, the enemy of any system (be it computer, biological or otherwise). When things stop flowing, eventually so do the systems that contain them. This is especially important in a corporate environment where process tries to make things universally similar across all areas, rendering the organisation sterile in the process. So Apple’s purpose in bringing in external members to oversee projects was to create a self-regulating system that ensured that project members kept moving and never settled, thus preventing project entropy.
The Science of Batching Work
Another talk that was of interest to me was Don Reinertsen presenting on the science of batching work. Whilst developers who practice agile methodologies can appreciate the benefits of breaking work into smaller chunks, not many would understand the science behind this approach – or even that there is a science behind it at all.
Reinertsen talked about the importance of keeping batch sizes small. Yet instead of using specific agile terminology such as ‘iteration lengths’ or ‘continuous delivery’, he presented us with the ‘transport cost’ and ‘production cost’ concepts used in manufacturing.
In the context of software development, transport costs can be seen as the costs of delivering the deployable app into production, whilst the production costs cover both the definition and execution of work.
Keeping this in mind, Don made some important observations relating to batch size:
- Larger batches are statistically proven to invite more work – eg. “since you are doing X, can you add on related task X1?”
- In corporations where the budgets are allocated to projects, larger batches of work (ie larger projects) means bigger budgets. This in turn attracts other teams/departments to associate themselves with your project so that they can share in the resources and have some of the budget allocated to themselves. This is not a good thing.
- There are lots of places to hide when work is done in large batches – accountability and responsibility are reduced
- By having a smaller batch, you get faster feedback. This shuts down unproductive paths more quickly. Furthermore, it helps us put words to things by having us experience them more often.
- Finding the optimum batch size concerns finding the best middle ground between transport costs and production costs. It doesn’t have to be perfect, but getting wrong will see the total cost and production time balloon out.
- Deploying regularly will reduce the transport costs in the long run, as people can both optimise what they are doing frequently, as well as put words to it
After the talk on batch sizes, I went to a talk given by Mark McGranaghan of Heroku on the lessons they have learnt on scaling. In some ways this reminded me of the theories of transport costs mentioned in Don Reinertsen’s talk. It also touched upon some of the concepts of software entropy that Mike Lee mentioned.
Heroku has billing and provisioning APIs that their customers use to run-up new services. The two APIs work together to ensure Heroku are giving the customer both what they ask for and what they’re paying for. Heroku has faced challenges with their transport costs when they needed to release new versions of these APIs.
Mark talked about 3 interesting things that Heroku do in maintaining these APIs:
- Hot Compatibility: Keeping version 1 and version 2 of your app alive simultaneously, including strategies for managing the database, caching and ticketing so that messages go to the correct version, as well as choosing the right time and approach for decommissioning the old version.
- Gradual Rollouts: Using ‘feature toggles’ to introduce new features to just a subset of users, then progressively increase the size of that set
- Gameday: Explicitly simulating failure in an upcoming environment to test that their hypothesis are ok
The ‘Gameday’ technique is of particular interest. Heroku would put people in a team to test a specific failure scenario and practice trying to fix it. This is reminiscent of the practice that Mike Lee talked about at Apple, except that at Heroku, the interloper would be in a separate room deliberately trying to trigger new, unexpected failure scenarios – or in other words, creating entropy. The result of Gameday was that the devops people and developers got better at what they practice and could react to real-world failure scenarios more effectively.
’till Next Year…
Overall, YOW! kept true to form, showcasing ahead-of-the-game, cream-of-the-crop speakers and ideas. Some common themes for me this year concerned embracing entropy to improve the resilience of your systems, and reducing the time spent doing repetitive delivery tasks by thinking more scientifically about how you batch up work.
I look forward to see how we can build on top of this and what it will lead to at the next round of talks next year. Bring on 2013!
No Comments