The Value I Gleaned from the First Daugherty Hackathon

The Value Gleaned from First Daugherty Hackathon

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:

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.

Team Daugherty Hackathon 2017 from Daugherty Business Solutions on Vimeo.

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.”

to this:

“The user logs in, clicks check credit and sees their credit score.”

…upon completion…

“The user logs in, clicks check credit, verifies their name and sees their score.”

…upon completion…

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.

John Mollberg
JohnMollbergSoftware Engineer & Associate Consultant

John Mollberg started at Daugherty in June of 2016 after graduating from the University of Minnesota with a B. S. in Computer Science. He's been interested in technology and problem solving since a young age and still finds himself tinkering with new gadgets on a regular basis. He spends his free-time boxing, playing board and video-games, and going to concerts.