What I have learned from a hackathon

I’ve attended a hackathon yesterday, that was the first “real” one in my life, and i’m still a bit under the influence. It was organised by the great people from Osijek Software City, and i thank them so much for the experience. I’ve learned so much, and almost nothing technical, because hackathons aren’t about it, as you will find out.

The topic: Crowd funding application

The topic was to make a simple crowd funding application. Nothing really complex, just a basic feature list with points for each complete feature.

The implementation: Rails

We chose Ruby on Rails as our implementation platform. That was a great choice, as we know it so well, and it would show later, that rails was the best framework for the rapid prototyping needed to win the hackathon.

The only thing lacking, where we lost a lot of points, was the front-end design, but you can’t expect a team of 3 backend developers and one software tester to create something really pretty. Although our UX was great, as we were using bootstrap, and not really in a great way.

The mistakes…

Overthinking it

We had a feature list to complete, which is fairly easy to do with rails, but we managed not to complete every functionality, just because we were loosing time hacking on the front-end to make it look acceptable.

Making it too complex

In a hackathon, time is working against you, you can say the same in product work, as unlimited time time is a thing no one has.

You have to make your features concise, and make them do only the stuff that needs to be done.

The learning…

KISS

Keep it simple, stupid. The best thing anyone can tell you, for any kind of product. Make it do only a couple of required features, and make that features well. Everything else doesn’t need to be done, at least at the moment. Don’t overthink the implementation, there are many currents in the rails development world which pull to this side or the other, but in this case, i must lean to @dhh and the pure rails way. You can optimise and improve later, after you have a product that is selling, and only the things that have to be optimised at the moment to keep the product running smooth.

Time is scarce, so make use of it

You don’t have time, as you are reading this, you have less and less of it. If you are still wasting it on nonsense, you won’t accomplish anything tangible. We had about 9 hours to make the application, and looking back, it was a couple of hours more than we needed, but we wasted time on initial configuration, setting up stuff, design. Lesson learned from this, Do the thing you are best at, and delegate everything else, if you can’t design to save your life, hire a great designer. If you can’t code, hire a great programmer. Just go outside, mingle with the community and you will surely find someone to team up with, if that isn’t the case, ask some of your acquaintances or friends, they will probably know someone who can help you build your dream.

Have a great team

The crucial thing any team needs is great communication, you don’t need ninjas, rockstars and whatnot. Anyone can build a web app, including high school kids who did a great job yesterday, i’m really happy that kids are going this path, as that will make their lives better.

Have fun

The main thing you are building a software product shouldn’t be money, or investors, but to have fun while doing it, if you aren’t having fun in your life, what is it worth to you then. I really like this job, and the people in the community are nice, if you are nice to them.

Final notes:

We had fun, we worked hard, i was swamped after spitting ruby code for 10 hours straight, and the experience was great. I met new people, had some interesting conversations, and saw other technologies people used to solve the same problem. We finished second, with a point difference of 15 points(the total possible was 1000), but it doesn’t really matter. The real reward is participating, and staying until the end, giving your best to solve the problem in hand, and supporting your team, as much as you possibly can.