This weekend I had the pleasure to attend the CancerDataDive Hackathon hosted by ProductForge at CodeBase. The general idea is gather around a bunch of young enthusiasts for an intensive work and try to come up with cool innovative ideas and proof-of-concepts. This is a great idea for an institute to get developers pay to contribute their skill and capabilities for its endeavor. I also learned that sometimes companies use Hackathon as a recruiting tool. To be honest, I think it’s actually a good idea as you get to see people work and interact with others in something that does feel like fun (as opposed to “feels like work”). I have some reservations as this intensive, incredibly-loud and overly dynamic environment doesn’t really represent real-life (and defiantly not my cup of tea), but still – coping with such intensity should qualify as a good trait.
My 2cents would go for the team-formation-part as I was rushing for another event and I tried to make it as efficient as possible. Fortunately, I immediately targeted the single person who mentioned he had an idea for a project and teamed up with him (later to be joined by 3 other gentlemen). The rest of the people were struggling to both find reasonable teammates but also come up with a startup idea at the same time. I think it might have been much more productive if we could first brainstorm ideas and then create teams based on commitments to ideas rather than “well, these folks don’t strike as psychos, now we need to think what we can”.
For whatever reason, my team decided to base our application on Meteor.js. As I admit that my preferred style of vanilla.js is not feasible for fast-pace project I agreed, hoping to learn more about this framework.
We didn’t try to publish to mobile app, which Meteor presumably allow so I cannot comment on that but I can tell that I found myself cringe as Meteor expect/allows you to write the db-access function in the front-end. In that sense, it doesn’t differentiate between client-side and server-side at all. This flaw isn’t crucial only when you have (near-to) unlimited bandwidth, otherwise your app will falter once you’re actually trying synthesize large volumes of data and send to the front-end only a sub-set. You, as the developer, won’t have the ability to handle it.
We actually came to this problem as reading data from the database happens presumably synchronously but in reality it returns an undefined value only for the function weirdly run in a loop until the data is retrieved. That’s probably one of the worst ways to hand asynchronous command. Instead, I would have advised to pause the code until a response is retrieved (mind not to hog the cpu, though – only the thread) or fork to a separate thread once the data is retrieved.
Another task I found unreasonably daunting is updating a the screen once it already displayed. Yes, I could simply write to DOM myself (which I eventually did) but as Meteor is based on Mustache.js, I didn’t find how to tell the template to re-run itself.
Lastly, accessing component’s variable kept changing depending on the current function – one time it’s this.variable, sometimes it’s this.data.variable and other times it’s Template.instance().variable. Weirdly enough Template.instance() doesn’t indicate which template is being referred so calling a template’s function from a parent function might introduce the wrong template’s scope. Ultimately, for the quick-and-dirty job required, Meteor pulled through, without wasting too much of our time, but for longer hauls I’d rather go Vanilla or any smart framework.
That said, I did enjoy rapid development. It’s incredibly reckless (no time for testing) but I understand why customers would like it as it provides results very quickly. We discussed the financial cost of medical errors, which amounts to roughly 25% of the ministry of health’s budget – and let’s assume this number is right for software bug fixing as well – how much time/resources should we spend on writing tests beforehand? The cap would probably be 25% so I understand why customers would like to save that portion of the money but in reality it’s going to be spent one way or the other.
However, what I learned from this project is that development is incredibly unimportant for hackathons, which is quite sad for the amount of developers that attended – The entire event revolves around thinking about cool ideas and pitching them in 1 minute talk and then a 6 minute presentation. You don’t have to – in fact, you’re expected not to – show your working application as experienced taught them that 72-hrs-worth code is too likely to break down. So my advise is to simply not code at all, rather than make a beautiful mockup and a presentation filled with pictures of cute puglets. Yes, your presentation should talk about your ideas feasibility – both in the sense of development and in the sense of legal issue. That’s why it might be helpful to have an engineer-mentor and lawyer-mentor to give advise but generally – Hackathons are for people who collaborate on ideas and not necessarily on code.