After all the fun of day one I was a little late arriving at day two of YOW! Sydney 2016 and unfortuantely missed the opening keynote (booooo...). But I eventually arrived back at the old Redfern train workshop, this time brandishing the Pythonic Staff of Enlightenment...
...and all set for anther day of interesting Software Development talks.
Below are references to my notes from specific talks. You can check them out collectively in a github repo here.
First up Sean Chittenden from leading Open-Source tooling company Hashicorp espoused the virtues of Incrementalism: A Strategy For Adopting Modern Automation. His metaphor of the environment as a factory made a lot of sense...
...particularly as a fellow Ops Guy who spent many years in an "awful almost-static CMDB universe". He sensibly recommended moving to dynamic secrets management using Hasicorp's own Vault as well as DNS-based service discovery and of course Terraform for provisioning. His take home points:
- Codify Everything
- Pre-plan outcomes at build-time
- Create reproducible artifacts
- Idempotent APIs and Tooling
- Developer-centric Operations
- Make small, well-understood changes
- Start where it makes sense for your organisation
Continuing the DevOps track was Dave Farley presenting The Rationale for Continuous Delivery. He discussed CD as the logical extension of CI and the difference that an improved cycle time can make to an organisation. Having practiced CI I honestly didn't require much convincing of its virtues but Dave reinforced some good practices such as bringing painful parts of the process forward to demonstrate to all concerned the value of working towards CI adoption. He also noted some of the common excuses for not adopting CI and some useful counters: if somebody at your organisation says it's not possible to release so quickly/regularly kindly inform them that Amazon release to >10k hosts every 11.6 seconds.
After a short break to imbibe the Dark Brown Liquid of Concentration, Uncle Bob Martin was up on stage once again. This time he was discussing a thorny topic that is of great interest to me: estimation. Bob presented a helpful formula for estimation which attempts to account for unknowns and re-iterates one of his key points: estimates should be ranges rather than fixed dates:
A key point was something that I learned many years ago: we must be willing to say "No" to the impossible rather than saying "Yes" and then underdelivering. When asked what to do in the case of an "absolute" deadline Bob's advice was to trim features. Adding people is another option but it is important to remember that for the first few months those new people are likely to slow produtivity before they increase it. An organisation needs the scale to be able to absorb that.
I really didn't know what to expect from Jon Manning in his talk How Do I Game Design? Design Games, Understand People!. But I was an avid gamer for many years and always had an interest in the industry so I figured it would be interesting. I was right!
Jon (fittingly dressed in a lab coat) discussed the core idea of "fun": what it actually means, how it differs in games as opposed to other mediums and how the design of a game ultimately evokes fun in the player. I found this truly fascinating, particularly his discussion of game mechanics (set by the designer) which in turn create dynamics (things which happen when the player interacts with the mechanics) and ultimately create aesthetics (the emotions experienced by the gamer that are the "fun"). The example of Half-Life 2's infamous Ravenholm brought back great memories: the complete shift in game mechanics (from abundant ammo to scarce ammo and poisoned head-crabs that immediately sap your heath to 1) made for interesting new dynamics and ultimately terror, fear and fun for the player!
While we're not all game developers Jon pointed out that we can apply similar methodologies to user interface design. Beginning with the aesthetics we wish to evoke in our users we can work back through the dynamics which might bring forth those aesthetics and finally build the interface mechanics required to allow those dynamics to emerge. Awesome stuff.
Emily Webber's Communities of Practice: The Missing Piece of your Agile Organisation was another talk which resonated with me. Having previously worked at a large-ish organisation who attempted (reasonably successfully) to apply the agile scaling practices of Spotify I recognised the similarities between a Community of Practice and Spotify's Guilds. I remember voluntarily joining the Python Guild/CoP and finding enoromous value in being part of such a community existing outside of my regular team.
Emily recommendations for starting a CoP were also remarkably similar to my own experience starting our makerspace SparkCC. The process of forming a loosely-knit group of like-minded individuals into a more formal community, helping that community to mature and encountering some of the more common pitfalls along the way were all stages we experienced over the past 1.5 years as we grew SparkCC into the established 'space that it is today. The various "levels" of member were also familiar to me not only through the SparkCC community but also through my involvement in Open Source projects. Members exist on these various levels and move between them over time:
- Core (you need at least a couple of these)
- Active
- Occasional
- Peripheral (lurkers who watch but don't take part)
- Outsider (not a member but might be involved in some way)
Rounding out the conference was SafeStack co-founder and all-round Security Sorceress Laura Bell talking Simplicity, Complexity and Security. Laura discussed the particular challenges of building secure systems in an agile world characterised by a high rate of change and an increasingly complex stack of emergent technologies. In many (most?) cases security is generally considered an afterthought, something to be applied after an application is "mature". This was a bad approach to building Monoliths in which we had one big, hard-to-rationalise ball-of-code but it utterly falls apart when applied to a Microservices architecture comprised of lots of small, hard-to-rationalise balls of code. Laura asked the pertient question: If you can't draw your architecture on one page how will you find the gaps?
Some of the key suggestions for mitigating this emergent security shortfall were to by all means Automate All The Things but also take time to understand the way in which this automation works so as to identify potential security holes. Start by documenting your infrastructure! With the vast increase in tooling required to achieve this automation this advice went hand-in-hand with the directive to only run code from trusted sources and to get involved in the Open Source projects which make this all happen. There's no excuse to not be improving the tools you use and pushing those contributions upstream. Ultimately while it's exciting to be a Pioneer, it's in all of our interests to strive to become Settlers as soon as possible.
With that all that was left was for Dave Thomas to thank all concerned and officially declare it beer o'clock...
Another interesting, insightful and thoroughly enjoyable ediiton of YOW!. See you next year!