It’s been a pretty awesome first day at goto; in Aarhus – after the first keynote, I found myself gravitating towards the DevOps sessions, which were really interesting. The .NET track was also good, and I was sorry to miss Rebecca Parsons – whose idea was it to put both Rebecca and Jez on at the same time?!
They presented a news reader and a cool clock project running in the browser, both written in Dart.
.NET track: Conventions – make your code consistent
Mark Seeman presented an interesting and very technical talk, using dependency injection with Castle Windsor as an example of where we can introduce conventions to reduce the amount of code we need, therefore making the code more maintainable. He used a series of well prepared code examples, also demonstrating the app working, to make his points. By describing the conventions we want to use within the code itself. Enabling conventions make it more straightforward to extend the code using the conventions, restraining conventions such as unit tests ensure developers are following the conventions in place. Mark presented an interesting example of a unit test used to prevent references to the DI container popping up in any assembly except the outermost one.
DevOps Track: Evolving Continuous Delivery
Like all of his DRW colleagues I’ve heard speak or follow, Chris Read succeeds in making me quite jealous when he describes their working environment, with clients sitting next to developers, and happy to accept a higher level of production bugs than most places I’ve ever worked! This acceptance of risk means that they are able to push out changes within 30 minutes of writing the code – on average. What I liked the most about Chris’ talk was the message that the things we’re told when we start doing agile – continuous integration is important, automate tests – still hold, but the implementation of them varies greatly. Just like with agile practices, how we manage continuous delivery must also vary to suit the team.
DevOps Track: Scaling DevOps
Jez Humble’s talk was polished and engaging, covering the need to bring ops and development together in large organisations in order to deliver better quality software, faster – which is of course what he’s best known for writing and speaking about! The two key insights for me were that reducing the cycle time will mean people are less than 100% utilised (and conversely, aiming for 100% utilisation increases cycle time), and that deployment pipelines can actually be a great tool for helping audit software delivery, possibly for SOX or ITIL compliance. I only wish that more companies grasped these concepts from the top, and used them to manage projects.
DevOps Track: DevOps Fools, Tools, and other smart things
Patrick Debois’ talk was focussed on how tools can help us to change our ways of thinking, and cultures. He talked how tools can encourage about collaboration and how two people from different backgrounds, like development and operations, can combine to make “creative chaos” – and that may not see the benefit of collaboration until we look around to see its effects. He emphasised that we should use tools to find new ways of working – be creative and look under the hood. If a tool only has one way of using it, that’s a problem – given an API, we can find new ways to innovate with the tools we have.
.NET track: Developers have a mental disorder
Greg Young was loud and entertaining, the perfect talk for nearly the end of the day. Taking the view that abstraction is “programmer porn” and developers love to solve problems that nobody actually has, with abstract solutions, he tore holes in many common development practices. A couple of things that made me think: it’s easy to measure DRY, but the flip side of removing duplication (coupling and complexity) is much harder to measure, so we optimise for DRY. Many tools take away the pain we cause ourselves by writing bad code, making it much easier to do just that. Most complicated problems can be worked around without the tools. Many of his observations had me laughing, or groaning in recognition, but I still have no idea how to convince others of the truth behind them.
Keynote: Cool Code
In other careers, like writing for example, we would look at other people’s work, particularly good examples of it. Kevlin Henney suggested we should do the same for code, and produced many examples of “beautiful” code. Some is literally beautiful, like the C program that depicts a part of the globe – and when run, outputs itself with a 45 degree movement. Another example was the chess program as long as 4.8 tweets. Some of the best code will never be used in enterprise applications, but it’s ingenuity and sometimes sheer playfulness makes it provocative.