From 0 to Automated in 20 Slides

Hey everyone, my name is Steve Workman, I’m a web developer living in Reading and I work for a company called PA Consulting in London. I’m also an organiser of the London Web Standards group, and have been for a few years now. Most of my work is to do with making the web better, and faster for everyone, but I also like making life easier for my team of developers, and for that we need automation.

Let’s face it, the world as we know it wouldn’t exist without the invention of the assembly line. Whether that is 20 people sharing out tasks in an order or a completely automated production line, this way of working, an individual dedicated to a single task, passing the results on to the next stage, increases the speed at which we can get a product, and it is the enabler of what we know as mass production.

And by mass I really mean millions of items per day, which was a pipe dream in the early days of the Industrial revolution, like in this classic picture of the steel works in Barrow. Much of the work done here involved a lot of labour, only involving machines for large jobs. For true mass production, you need automated machines, or as we know it in technology, computers.
For this talk I thought, what can I give as an analogy for mass production that is relatable to everyone and I know quite a bit about – well, my wife works for a large chocolate manufacturer – problem solved! (note, picture above may or may not be for her role).

This company makes 3.2 million bars per day on a single line, for the UK region alone! To do this kind of scale with industrial revolution techniques you would need an entire city full of people, though this line runs with a shift of around 20 people.
And it’s not like it’s an easy job, making chocolate is a very complicated process that takes hours from raw materials to bars, and whilst people may think that it’s like stage 13, pouring chocolate into moulds, the whole process is much bigger and complex than this – which is why it must be automated to work on scale.

I think there is a lot that the web industry can learn from this kind of manufacturing. Automation allows developers to perform labour-intensive manual tasks like deploying an application into quick scripts to save developers huge amounts of time, and make the whole process much more reliable.
In my own personal experience, back in the early days of iPhone development, we didn’t have an automated process, and code was strewn around a number of different laptops, making it very difficult to track down code and sometimes it would take us about a day to build and deploy the app. It now takes about a minute to do everything.

We took on the principles of the manufacturing line to make what we do better. Developers need a factory, and that is their server room. If a developer has to walk over to another computer to make an automated process happen, it’s not an automated process. For me, this is where my application servers live, and this is where my build server lives. This is my factory
We have developers - they are the farmers, harvesting source code and creating the raw materials to make our wonderful chocolate bar of an application. Developers have to supply quality raw ingredients, quality source code, to make a great application. Developers have coding standards so they know how they should write their code to make it work as part of the recipe

Developers normally store their code in source code repositories, like they are sending their over the information highway to the loading depot, where all the ingredients will be combined to make this lovely application. The two most popular of these are subversion and git – subversion being more like a traditional factory, and git being an at-home 3D printer.
Then we have our recipe, the instructions on how to combine all of our ingredients together. Traditionally this does things like compiling the code, but it’s also about applying performance enhancements that you wouldn’t want to develop with. It’s like taking cocoa beans and turning them into cocoa liquor so they’re the right size for your process. This recipe is called a build script.
Over the years, build scripts have evolved from the original, and still widely used, Apache Ant, a simple worker that you specify tasks to run, then there’s maven, which also handles a project’s reporting and documentation from a single, central piece of information. More recently, we’ve got Grunt, a build script that encourages plug-ins so you can enhance it and do whatever you like. It’s like instantly summoning a new machine from a third-party company to do a complex piece of work for you.

Then we have our control room, and for me this is a piece of software called Jenkins – it takes the ingredients from the loading bay and runs them through the recipe. Other bits of software that does the same job are available, but Jenkins is free as in free beer, and the icon is a butler, which is a big plus in my book.
Jenkins watches for what is going wrong. Like modern factories, you set thresholds for quality, and you can monitor when things are starting to go wrong, and keep it in check, to bring it back within its quality spec. You wouldn’t want a chocolate bar with a gritty, high particle size, and I wouldn’t want an application that was over 2MB to download on the page, so you can monitor this and get those warning signs sent to you via e-mail, sms, or chat.

The important bit is to make sure that your combined recipe is actually up to snuff. In the chocolate world, about twice a shift, the operators unwrap and check up to 150 bars out of the tens of thousands that have been made, simply to check its quality – and that’s attention to detail.

In software, we try to automate this as much as possible, and give ourselves traffic lights to say when things are working well and when the quality is off – something doesn’t work. When it doesn’t work, it looks like this – some nice green tests, then a big chasm as tests fail and everything breaks. These are needed to trigger the factory alarms and shut down the process. The last thing you want is this poor quality product getting out into the general marketplace – and these tests and alarms stop that.
Obviously, the quality of your checks matters a lot, and the better they are, the less likely you are to produce bad code and a bad product.

The massive advantage that software development gives us is that your workers are other computer programs, tiny little ultra-fast robots that never tire, never go on a coffee break. They can perform practically any task you want to get your lovely app into ship shape. Say, when it’s done, you wanted your app to be submitted to a service like TestFlight so you can automatically send your app to testers.

But just because the little robots are very fast, doesn’t mean they’re indestructible – in reality it means they fail faster, and often without much warning. That little robot that sent the app to TestFlight won’t have anywhere to send the app to if TestFlight changes their API. These programs need maintenance, and it won’t just be because of third-party services that your robots will fail – your app itself will change and need to do different things over time, so you have to keep tweaking the program to make sure it runs like the well-oiled machine that it should be. In the chocolate world, people with the toolbox, those in the reliability team, have one of the most important jobs in the factory – to keep it going so that chocolate can reach consumers as quickly as possible and in as good a quality as possible.

All of this is really important so you can keep innovating, keep shipping, keep distributing and gather feedback from your users as fast as possible. Innovation and ability to react are two of the defining characteristics of startups and lean organisations. Keeping your factory running as fast as possible is vital, and something software houses should invest more in.

So, keep shipping, keep those little robots moving, and importantly, buy chocolate