Last weekend I attended an event at the Centro de Referencia Nacional de Desarrollo Informático y Comunicaciones in Getafe. Long story short: I went to a hackathon that was not a hackathon and I won!
The event was called Hack a Startup and it was advertised as a hackathon or “programming contest”. I had never been to a hackathon before, and the idea of going to one had been on my mind for the last couple of months. So when I received the email, five days before the event, I signed up.
I had not attended a hackathon before because… to be honest, I don’t know! I probably was just afraid of exposing myself to program with other people after 10 years of doing it on my own. Anyway, I found myself looking for excuses not to go, which usually means that whatever I’m trying to do is taking me out of my comfort zone. And I have learned that getting out of my comfort zone is the only way to improve.
The event took place on the afternoon of Friday, July 5th, and Saturday 6th. I must confess I was a little nervous and excited when I got there - felt like staying there and running away at the same time. I went on my own and knew no one there. Soon after I arrived, the organizers explained how the hackathon was going to work. It was then I realized this was not a programming event - but a business-oriented one. When I found out, I considered leaving, as it was not what I expected. I found myself looking for excuses to run away… so I decided to stay. If I wanted to get out of my comfort zone this was an even better opportunity to do it.
Not running away turned out to be a good decision
They turned out to be a great couple of days: five companies presented five challenges to us. We had to work on those problems in teams of up to four people and come out with a sort of MVP that would be pitched on Saturday. The first day we had to work on the business model on our own. The second day we had several interviews with the companies in order to prepare our MVP and the presentation.
At around 5pm on Friday the teams were ready and we all had chosen the challenge we wanted to work on. I opted for the one posted by i-solagua who had a fascinating project about the optimization of watering and fertilization of land. Following the lean startup methodology, we conducted a first exercise to identify the stake holders of the project. Afterward, each team had to create a Lean Canvas for our project and discuss it with the other teams. At the end of the evening we had one minute to pitch our idea on stage in front of everyone else. I had read a little bit about the lean methodology and doing that exercise was a great way to practice and ask questions. I knew about the canvas, but working on it with a real project helped me really understand the tool.
Saturday started with a nice breakfast and a meeting with the people from the company to ask questions and gather more information about the problem they were trying to solve. Then we had until 6pm to prepare whatever we decided to present. During the first meeting Ricardo, from I-solagua, told us about the status of the project. The first thing to work on for me was to become familiar with the domain and it’s language which is one of the first and more important things you need to do according the book Domain Driven Design. I learned about fertigation, what kind of sensors they use to monitor the status of the crops, how the information is gathered and how they are working with the Centro Tecnológico de Castilla y León in order to develop predictive algorithms to process all that information and help the growers to irrigate more effectively. He showed us a couple of web applications they already have to control the irrigation pumps and display information from the different sensors on the field. Learning the domain language was our first task, the second was to listen. During that meeting we had to find out what problems we were going to solve. Ricardo made this task quite easy, actually, because he complained several times about the usability of the tools they had at the moment.
Once the interview was over we had half an hour to decide and plan what we were going to present at the end of the day. I had a look at the schedule again to see how much time we had: three periods of one hour. We had two options: we either prepared a few slides, or did a mockup of the application using PowerPoint / Marvel / a similar tool or create a simple web application which showed what we had in mind. Talking to my teammate, Juan Pablo, we decided to go with the second option, even though he had not much experience developing web apps. I would program a rails application and he would help me with styling and searching some stuff on the internet.
It was an intense afternoon, but we managed to create a working proof of concept of the control panel for the growers. You can have a look at it in github. During the last hour, Juan Pablo worked on the three minutes presentation while I was fixing some errors in the application. We even had time to rehearse it a few times before we all gathered together in the auditorium to present our work.
…and we won!! A tablet and a smart watch. Not bad for nearly having run away the day before.
What I liked most
- The event schedule was followed quite well. Guillermo was constantly keeping track and informing us about how much time was left. This helped a lot to keep the focus on the tasks we were doing.
- The schedule was split in sections, from 30 minutes to one hour. In between those sections there was a recess of a few minutes which included a performance. It was a great way to really force us to stop, rest and set our focus on the next task.
- The people from the companies were involved and showed genuine interest in what we were working on. At the end of the event, three companies announced that they were going to contact the people that worked on their project to keep working on them.
What could be improved
Even though I really enjoyed the event, there was some room for improvement:
- I would not call this event a hackathon nor a programming contest - the name was misleading. Maybe something like “lean startup contest” would have been more accurate, because that was we were doing there: preparing a prototype or MVP using the lean methodology. As mentioned above, I only had 3 hours to code.
- There were three groups working on the challenge proposed by i-solagua, and all of them consisted of programmers. We were missing other profiles (e.g. graphic designers, UX experts, product owners), whose presence would have made it much more enriching.