HackUCI: Hard Lessons Learned
My colleagues and I have gone to enough hackathons that we feel like every future hackathon is obligatory. HackUCI fitted right into that category, except for the fact that it was definitely an emotional one. We failed to realize that we were moving too fast without solid planning. In the end, we could not deliver what we planned to, but I suppose that was a relatively low price for several valuable lessons learned.
It was already week 8 of our 10-week quarter; our main software engineering project was going to be due in 2 weeks, not to mention other class assignments and final exams were starting to creep in. The stress level was quite high. We still wanted to go; plus it was Memorial Day weekend anyway! This time, the team only consisted of Ankush A., Josh A., Aieswarya M., Elle N., and Michelle W. All 6 of us met the night before to discuss what we wanted to do, a preparation strategy that we found useful every time.
The idea this time was a platform that would enable people to communicate via different mediums (Facebook, iMessage from iPhone, Message from Macs, Google Chat, and email). Since Twilio was one of the sponsors, we wanted to utilize their API to handle the texting component. Ankush and I started playing with the Twilio API. After a few hours of struggle, we got a few messages sent from the API to our phones but… we could not reply to the message. Things started to fall apart when we failed to create an OS X application to interact with Mac’s Message, not to mention Facebook and Google Chat. The team’s morale started to shatter since none of us could really make any progress on our part.
Ankush and I were very baffled. We carefully split the project into parts according to each member’s expertise the night before, yet why was it that none of us could make any significant progress? As individuals with project management experience, we took this failure very seriously and wanted to prevent it from happening again. We hypothesized that the academic stress and the lack of knowledge of available technology were the reasons. There were too many assumptions about Twilio API’s capability and integrability. For all future software engineering projects, we would have to make sure that available technologies/tools must be able to support the features we want to deliver; we must have absolutely zero pre-assumption.
It was the very first time we did not deliver a product at the end of a 24-hour hackathon. Yes, I was disappointed, but I personally did learn a lot about planning and managing software engineering projects in the future. It’s going to be one of those experiences that will guide me for better project management in the near future.