At Small Improvements we each have a learning budget and get to choose which conferences we attend. It might seem a bit of an odd choice then that I stepped off the plane in the Lithuanian capital Vilnius on a cold November afternoon. I was there for BuildStuff, a pretty special conference. The lineup was one of the best I’ve seen in a long time. Kevlin Henney, Simon Wardley, J.B Rainsberger, Linda Rising, Dino Esposito and Jurgen Hoeller (to name but a few) all graced the stage over the three day event. I was in my element and eager to learn, here’s a few of my top take aways.
1. DevOps is the new legacy, serverless is the new norm
Simon Wardley took the opening Keynote at this years BuildStuff. He started by describing his journey as a startup CEO with a generic business plan to discovering mapping. Maps are important because they guide you on a journey, much better than a set of instructions. All maps have some basic elements. They are visual, context specific, have positional components (based upon an anchor) and show movement. Simon explained that current business planning tools (like SWOT) don’t fit these criteria. He eventually devised his own method of mapping a business. You can read more about Wardley Maps here.
Using his technique, Simon mapped out the evolution of infrastructure and architectural practices. Practices move from left to right across the map as they gain adoption and later become institutionalised. New evolutions of those practised start out on the left again. Using this technique we can see that DevOps is reaching the point of commodity. As each new technology abstracts away from the previous (server racks -> compute -> paas -> serverless) we can see that serverless is an evolution of DevOps. Because the old “best practice” practice becomes industrialised and benefits from the speed and efficiency, we tend to ignore the new “Genesis” practices for a long time (too long some would say).
2. There is no sprint zero
Martin Hinshelwood was there to remind us that there are no special sprints in Scrum. He described Scrum as the minimal framework required to implement agile. Hence we must be thinking of the agile manifesto in everything we do. Even in a team that doesn’t use Scrum (we use Kanban in our team as Small Improvements), this still rings true.
The first of the twelve principles of Agile Software states
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
By having a sprint zero, planning sprint, or other such planning phase we are breaking this first principle. Our aim is to get something in front of the user as quickly as possible, gather feedback and use that to iterate.
This is something we often forget in software development. We spend valuable time perfecting our new feature but until someone is using it we’ve no idea if it’s actually useful.
3. Everyone should be doing chaos engineering
Standing there with his electric guitar in hand, you’d be forgiven for thinking you’d made your way into a rock concert for the day two closing keynote. In fact Russ Miles (who can really play the guitar by the way) treated us to a slice of chaos engineering. This is a topic that most people are aware of through Neflix’s Chaos Monkey project. Chaos Engineering is actually an architectural practice that everyone can do. It’s important to note that this is not just terminating servers to see what happened. Setting out some guidelines, Russ explained:
- Learn the healthy state of your application in production before attempting chaos engineering.
- Always run experiments in productions.
- Run experiments where you expect the system can cope (not where you expect everything to blow up).
- Start by varying real world events to limit the blast radius.
- Make sure everyone at the company knows it’s happening.
4. Functional programming is hot right now
There were at least four talks on functional programming and many others mentioned functional paradigms. My favourite was by Sander Hoogendoorn who reminded us of the power of Monads. We’ve all been using Monads during development without even realising.
Optional in Java are both monads (there’s some debate about the latter).
What impressed me about Sanders talk was his explanation of Monads. We can think of them like putting a value in a box. When in the box, all the side effects (such as thrown exceptions) are hidden inside the box.
We can apply functions to the value in the box, transforming it (map/flatMap) and at the end we can take the result out of the box.
In another talk, Einar Høst was live coding an Escher Square Limit in F# based on a paper, Functional Geometry by Peter Henderson. Einar’s talk was a real eye opener to the beauty of functional programming. Using composition, he was able to write functions to scale rotate and tile the base fish image to create the Square Limit in 45 minutes and everyone was still following at the end.
5. Reading code is harder than you thought
Think about your job as a programmer, which do you do more of: reading code or writing code? Of course it’s reading. Every time we fix a bug, we have to read the code and understand what is happening. Every time we add a feature to an existing code base, we read the code first. Romeu Moura‘s talk on day three focused on reading code and how to keep our emotions out of the process.
When we read others code, we’re prone to thinking, “Who in their right mind would write code like this?”. Romeu started with Hanlon’s razor as a base for explaining why code is not always as it seems.
Never attribute to malice that which is adequately explained by stupidity
Maybe we can say it’s not stupitidy but ignorance (a lack of knowledge) that caused the developer to write it like this. Or maybe it’s not even ignorance but lack of attention. After all we are all human beings and we’re not blessed with infinite attention spans.
But what if it was not lack of attention but unstated context that causes the code to be like this? We all write code we regret when put under pressure to finish features.
He went on to explain that the systen in which the code is written (i.e the development culture at the organisation) is the cause of bad code. Luckily at Small Improvements we don’t suffer from this systematic bad code.
Grab your coat…
The three days of conference were so full of content that I couldn’t possibly write it all here. With multiple tracks, there was always an interesting talk to attend, not to mention a few hard choices. The conference itself had a constant flow of food, coffee, popcorn (and a wheelbarrow of oranges for some reason) and an excellent party on the Thursday evening. So if you find yourself with a free week next November (who does anything in November anyway?), I strongly encourage you to book a plane to Lithuania and attend BuildStuff 2018. I will see you there.