When I learned Daugherty was having an internal hackathon in St. Louis, and was offering a $10,000 prize for the team that produced the best solution, I flew from Minneapolis with a few of my peers.
We arrived about 4 p.m. After a warm welcome, we received information about the project we’d build. The subject of the hackathon was data tracking and privacy and security. The use cases included:
- Store and restrict information collected about the user to the user’s country.
- Allow the user to completely erase themselves and any data gathered on them from our system.
- Require consent and some age (based on country) from the user prior to information tracking.
- Allowing anyone (not just users) to complain to the “commissioner” without an account.
- Informing users about any information sharing done.
- Informing users based on what country they’re in what and why we’re tracking them.
We were inspired to meet these requirements by providing a credit bureau system, and we had 40 hours until the presentation after getting the requirements. Little sleep was had, much cold-press coffee (delicious by the way) was drunk. By the end of our time, we did have a product, but it wasn’t as functional as we’d hoped it would be.
The Three Lessons We Learned through the Hackathon Experience
1. When you have to work fast (which is often), be agile. We followed this philosophy pretty closely, but not closely enough. After getting the requirements, we went to the whiteboard. We read through the use cases, created the workflows, then defined the data model. After that, we all got to work.
So where did we go wrong?
Pretty much right at the beginning. We defined the workflows, then defined the data model. That’s not the agile way. We were operating under the assumption that minimal viable product (MVP) was meeting all the bullet points outlined above, which turned out to be unrealistic for what we were making.
We got to the demo and had two to three workflows that were actually functional, and about six to seven that were about 60 percent complete. We’ve all been in “What you would see here if it were working” demos, and we went through this one due to lack of agility.
In hindsight, we should have done things more piecemeal. The story would change from this:
“The user logs in, clicks the ‘check credit’ button, enters their name, DOB, National Credit Identifier (NCI), address, etc. … then sees their credit score.”
“The user logs in, clicks check credit and sees their credit score.”
“The user logs in, clicks check credit, verifies their name and sees their score.”
Eventually, it would go back to the initial story. Instead, we ended up with about 10 required fields that once correctly entered, didn’t provide a credit score.
2. Code for your demo (as long as that’s all that matters). It might not seem like it, but eight minutes is not a lot of time. We ended up with a 30-minute application and eight minutes to show it. In retrospect, we should have coded for the demo.
Arguably, coding toward the demo in a standard engagement can sometimes be a mistake. However, it would not have been in this environment. Instead of spending 30-plus seconds (6.25 percent of our time) filling out 10 validation fields, we should have made the only field that matters your name.
We spent too much time doing “nice-to-have” features that the app would work without, rather than going back to the use cases and working on the easy-to-demo, low-hanging fruit.
3. Screenshots are your friend. We thought a live demo would be cool, but, realistically, given the time constraints (and thus fragility of the code) and the amount of functionality we were working in, a slideshow would have served us far better. We saw many other teams doing that, which was great.
Despite our failings, the Daugherty hackathon was a lot of fun. Everyone at the St. Louis office was very friendly and welcoming, and sleep-deprived people can do some pretty funny things (I spent a good 30 minutes figuring out why the app couldn’t find the “consumber” table — facepalm). Our project didn’t work out the way we wanted, but it was an incredible opportunity and learning experience. I am thankful to work for an organization that invests in its employees this way, and hope to participate in hackathons in the future.