HACKTRAIN 3.0 – AN INSIDE PERSPECTIVE
Written by Frederic Kalinke
Graham Prickett’s epic account of ‘hacking’ the rails at HackTrain 3.0
Everyone at SilverRail loves HackTrain and the buzz that surrounds the events. The energy is high and networks are built with like-minded people, giving our team a real stimulus which lasts way beyond the actual hackathons.
And so this year we had six participants and mentors take part in HackTrain’s latest hackathon – a 48-hour event bringing together software developers, designers, entrepreneurs and industry experts to create new technologies to help solve rail’s biggest challenges.
All six members work in different teams, roles and offices at SilverRail, with some travelling all the way from Brisbane and Boston to take part. Their roles at SilverRail ensured they all had more than enough rail and technical muscle to provide exceptional support to the participating teams, as well as bringing new ideas and skills as participants themselves.
To find out what it’s really like to take part in a rail hackathon, we stole one of our own mentors away for a quick post HackTrain chat. Enter, Graham Prickett, Senior Software Engineer at SilverRail, and mentor extraordinaire at this year’s hackathon. Graham rode the UK Train which specialised in infrastructure and data, and travelled from London – Colchester – Cambridge – London.
So Graham, what made you put yourself forward for HackTrain 3.0?
I’ve worked on the SilverSearch API for a number of years in a development and a support role. During this time, I have built up an understanding of a number of the different components of the system, but I was keen to put that knowledge to use by supporting developers who have never used our API before. As I’d never been involved in a hackathon before, I was keen to see first-hand what cool ideas the hackers came up with. I was also interested to observe what sort of processes the hackers followed when developing their apps.
How did you feel during the build-up to the event?
Excited and nervous at the same time. Having 50-plus people totally dedicated to creating apps and infrastructure for the rail industry is a really exciting concept to be part of. Yet being my first hackathon, there was also an element of nervousness, particularly as I was a mentor in a ‘teacher’ type position. Would I know enough about the API to support the hackers?
What were the hackers like?
They were mostly from the UK, a lot were in university and almost all of them were under 30. There was a great vibe and excitement among them. Some of the smartest brains around Europe had entered.
Tell us about the sponsors and the industry challenges they wanted you to solve?
Challenges were set from TFL, BAI Communications, Angel Trains, Nomad Digital, Arriva, SNCF, EY and Eurostar.Data analysis tasks such as analysing Wifi data, Lidar data for object recognition, to user experience challenges. The challenges were split between infrastructure and customer. The UK train was nominally the Infrastructure train and the EU train the Customer train. I was particularly interested in the TfL challenge – to use passenger boarding times and loading times to calculate in real time the optimal tram schedules for creating the least disruption to the network. In the Brisbane office we study a lot of journey planning algorithms but this challenge was one layer further from that, designing the schedules in the most optimal way.
Arriva also set an interesting challenge to use real time data in new and interesting ways to empower rail users with information when there are delays. The real time DARWIN feed was the data source. It is also used in the SilverSearch API so I was interested to see how this could be used to help the end customer.
How did the hackers form teams?
After being split into the UK and EU trains, we were asked to brainstorm ideas via one-minute pitches which anyone – hackers, mentors or sponsors – could put forward. The UK train had about 20 ideas. Some of them were crazy, some solved a challenge set by the sponsors, and others had nothing to do with them.
Once all of the ideas were in it was voting time. The 40 hackers and 10 mentors each got 3 votes to award to the favourite ideas. This was a fascinating process to watch, as good ideas could sink very quickly if hackers couldn’t make others see their potential – and bad ideas had the potential to rise if a savvy marketer was promoting it. Finally, 20 ideas had been whittled down to 10 and teams were selected for each, with the ‘inventor’ describing what sort of person they were looking for to help them progress it – hackers, entrepreneurs or front end developers. It was up to the idea architects to recruit the best people for their project, and it was up to the hackers to get themselves on the projects they wanted to be on. As soon as the teams were formed they got to work. A lot of the ideas pitched were embryonic, sparse in detail and not thought through, or based on a vague or incorrect assumption about the API or dataset that was available. So teams started discussing in more detail what exactly they were going build.
I was at this stage that a team (Haggle) approached me, as they were interested in using the SilverSearch API. They had an idea to use the TfL passenger data and SilverSearch API to create a new ticket type to encourage people to use services outside of busy periods. We were able to get them up and running with it very quickly. Another team (Cloudy with a chance of Delays) were also interested in using the historical DARWIN data. There was no DARWIN mentor on the train so Hugh (the other SilverRail mentor on the UK train) and I were giving support for it. Luckily we were able to use the services of local SilverRail superhero Jason Cheung to help us out.
Tells us about the train journeys – what role did they play in developing the team’s ideas?
On the first leg of the train (London to Colchester, about 9pm on Friday night), teams spread out as soon as they stepped onboard and they got to work looking at all of the datasets and APIs they would need. I was busy trying to help out team Haggle. The TfL data didn’t easily ‘marry up’ with the SilverRail data, and so I was on my laptop trying to figure out how the two datasets could be combined. Cloudy with a chance of Delays had decided to conduct an analysis of historical DARWIN data to help predict perturbations throughout the UK rail network in real time. To me, this sounded like a challenging task to take on in the short amount of time available. But at the same time, it had the potential to become a unique and useful piece of software.
On the second leg of the train (Colchester to Cambridge, Saturday 9am), most of the teams had decided what they were going to work on. They had split up the work and were now developing functionality. One of the teams (FlexRail) however, still hadn’t decided what they were building and couldn’t decide what challenge to work on. However, one of their team members, Sina, started talking to Hugh and I about an idea he wanted to do.
We didn’t know it at the time but he was pitching the winning idea to us! His idea was to create a new type of advance ticket where instead of booking a train at a particular time you book a train for a range of times e.g. 8am – 12pm. In return for your flexibility you are given a cheaper fare. The day before travel you are informed of the exact train you will be travelling on. The advantage for the Train Provider is that they get to spread people out over their trains, improving the customer experience. It also means providers can offer people flexibility of travelling time for longer because fewer people ‘lock in’ a time when booking. Hugh and I discussed Sina’s idea with him for a while, going over the pros, cons, and technical challenges he might face. In the end, we gave him our blessing and Flexrail finally got to start building their app.
On the final train (back to London), the hackers looked completely fatigued as almost all of the teams had worked through the night. The train ride was an opportunity to get some sleep (although HackTrain founder River stalked the train, trying to get teams to practice their pitches one last time before the finals.
Tell us about those finals?
There were some really polished presentations in the UK semi-finals. Having been worried at the start that no one would end up using the SilverSearch API, I was stoked that three teams (Haggle, SARA and FlexRail) ended up using it. Teams were given six minutes to pitch their idea to the judges – all industry professionals using the same criteria:
- Design and Pitch – 15%
- Business Model/Viability – 15%
- MVP Prototype – 70%.
Six minutes is not long. It was hard for the teams to get the details of their ideas across in this time. And it was hard for the judges to get a good idea of what the teams were doing. In some cases, the judges didn’t even have time to ask questions.
Five teams out of 10 from the UK train would go through to the final – four announced by the judges and one wildcard. I was so pleased when Haggle, Cloudy with a chance of Delays and SARA all made it through to the final!
The finalist teams gave their pitches one more time to the judges. Happily, again for me, the wildcard entry into the final from the UK train was FlexRail! The judges deliberated for a long time but eventually came out with the following result:
- AutoMappr – who took on the hardest challenge – identifying objects within the rail network using LiDAR data provided to them by SNCF. The team created an algorithm that analyses the LiDAR data and automatically identifies objects within the network and assigns them a name. Really impressive stuff as the technology is so cutting edge that only Google and Mercedes have been able to really get it working effectively in a real environment.
- Cloudy with a chance of delay
A really satisfying result for me. The winners had pitched their ideas to Hugh and I on the train yesterday. And 1st and 3rd places had both used the SilverSearch API.
What was most crucial to success?
Getting the most out of their time at Liverpool Street station on the first evening definitely impacted overall success, as this was the only time available for teams to approach the general public or rail personnel to ask them about the viability and usefulness of the apps that they were proposing to build. I didn’t know it at the time, but this was a crucial part of building a successful app. Market research such as this was viewed very favourably by the judges on Sunday.
The second was practising and fine tuning their pitches in front of the HackTrain founders on the Saturday evening, with plenty of red bull (of course). This proved great practice for the final, as River and the other mentors picked apart every team’s idea and analysed their business case and pitch. It was often a painful process for the teams to hear as often they walked out of the room with quite a different idea of what they were doing than when they walked in, but it was incredibly useful to get that frank and informed feedback. I believe this is the reason why the UK teams ending up taking the top 4 places in the final on Sunday. As a mentor, I sat in on as many pitches as I could. It was fascinating to hear what each of the teams had accomplished. And even more fascinating to hear how River and the other mentors took the ideas and pitches the teams came in with, broke them down and reframed them as a better business case.
What advice would you give to someone thinking of taking part in a hackathon?
Being a mentor there’s probably not much advice I can give to a hacker but I would just say give it a go. It’s a friendly, supportive environment and there is a great camaraderie among the hackers. If you enjoy working in a team and putting yourself under the pump to deliver, then this is the place for you. The rail industry looks to the HackTrain and hackers as creators of innovative products. It’s also a great place to meet like-minded people and get exposure to the rail industry.
What were your most memorable parts of the hackathon?
One distinct memory was traipsing through central London with 49 other “rail nerds”. Our presence met with curiosity and mild bemusement from onlookers.
Then there was the Sunday morning – when I work up at 08.40 with horror when I realised that our train departed at 08:32. Hugh and I had slept in and missed our train! We ran down to Cambridge station hoping that maybe it was late, but unfortunately, the departure board confirmed what we already suspected. We had missed the train and lost contact with the UK HackTrain. We were gutted. The only thing to do was jump on the next service to London. As we walked to our platform, to our amazement River was there. In fact, the entire UK HackTrain was there. The 08.32 had in fact been delayed by a signal fault! I’d never been happier for a signal failure, although the hackers were not so impressed, as they worried they were losing valuable time.
How would you describe your weekend to someone thinking of participating in a hackathon and would you do it again?
All I would say is: ‘what a weekend’. It was so much fun. I met so many new and interesting people. It was really positive and enjoyable. I particularly enjoyed witnessing the camaraderie between the hackers. I got to see how app developers use our API. I got to see how much effort it takes to organise one of these events. I’m hoping to share my experiences with the team in Brisbane and get more people interested in participating next year. I’d certainly be interested in participating again.