We started in 2008, making use of genetic algorithms (GAs) to evolve schedules based on user selection. It didn’t work very well. Although providing a good means to progressively narrow the problem space through user selection GAs aren’t efficient or particularly good at finding high quality solutions for the type of problems we were solving. Real world scheduling that caters for human nature and constant change is technically challenging. The launch of Amazon Web Service gave us access to the required compute capacity, but the available data was inadequate, integration complex, and channels to market were limited. Most people used printed programmes at festivals and didn’t have access to the web once they left home. The majority of tickets were purchased at shop fronts or over the phone, and delivered on paper. Digital mapping and transport datasets weren’t great for navigation and routing, particularly walking. The first iPhone had just come out. For most people REST was something you did when you got tired. We took a break.
In 2013 chance set us in motion again. With the help of generous contributors with expertise across a range of technologies and sciences, including combinatorial optimisation, machine learning, game theory and behavioural psychology, along with web scale API design and web and mobile development we reworked the service. The compute intensive back end lives in AWS, where we exploit the elasticity of the infrastructure to keep performance and availability high while keeping cost down. The beta API is exposed via Django REST Framework, which is heavier than we need now but gives us great agility. We can generate typical schedules in under a second, but have made the optimisation asynchronous to better decouple the back end, allowing us to scale components independently for more complex scenarios. Selective evolution still plays a part in helping guide us towards better schedules, but the heavy lifting is done by a mix more efficient algorithms.