Hackathon 2021: World Innovation Day

This year, Hackmakers hosted a global hackathon in support of the UN's sustainable development goals. My employer, Fitch Group, generously allowed a group of 8 of us to join the competition this year and work on a solution in the field of education (which is a core focus of Fitch's social awareness efforts). In this brief article, I'd like to capture a little of the spirit of the event as seen through the eyes of our team, as well as presenting the solution we crafted for your further consideration.

Where appropriate, I will call out the stages of team development as we proceed: forming, storming, norming, performing and adjourning.

Preparing for the Event

We first became aware of this event about 3 weeks before it commenced. It was very straightforward for us to secure volunteer time to participate in the event using pre-existing systems that Fitch has stood up for this purpose. The next piece after this was to recruit an appropriately-sized and skilled team for the event.

Recruitment (aka "Forming")

Past experience has shown that a key mistake many software development groups make either when hosting a hackathon or fielding a team to participate in such an event in to limit it purely to software developers. This isn't the way any project ever succeeds in the real world, so it shouldn't come as a surprise that hackathon efforts that follow this staffing approach also typically fail to thrive. One needs team members skilled in organizing, listening to customers, presenting, etc..

On this point, our team scored some great early wins, as we recruited professionals in these areas, as well as some of our top software developers. We proceeded into the event with a team of 8, all confident that we had the right mix of skills and backgrounds to let us succeed.

Training

The organizers sponsored a series of training videos in the week leading up to the event, which the team watched eagerly. The geographic dispersal of our team was such that 7 of us are in North America and 1 in India. This also came in extremely handy, as the organizers were based in Australia and tended to schedule some of the non-recorded content during times that were more challenging to North American time zones than otherwise.

The sessions were a mixture of technical content and "soft skills" training, where the organizers reinforced the importance of listening to the problem statements and putting together a compelling story in response, in addition to delivering on the technology goals. As pre-work for the event, we set up a team Slack channel for communications and began trying to set up an Oracle Visual Builder instance using the free account.

The Event

By the time of the event's start, we had finished creating a Visual Builder instance and simply needed to permission the rest of our team to it in order to get started using the tools with which we were all familiar: Spring Java, VueJS, etc.

Friday ("Storming")

The event launched at 6:30 AM, Chicago time on April 16, 2021. By this point, I had already been working on trying to grant access to the Visual Builder instance to the other members of my team for a couple of hours and was realizing that I was getting nowhere fast. One of the first things we would need to do as a team - on the technology front - would be to contact one of the Oracle mentors and find out what needed to be done to get us all onto a single instance of Oracle VBS.

Immediately after the opening presentation (which you can see me watching in the image), we meet up on our team's Slack channel and discussed how to kick off. We decided to hop on a video conference call to expedite the discussion.

We spent the first few hours discussing the UN Sustainable Development goals and agreeing upon a solution we would try to build. We wanted to build something that encouraged and enabled students and teachers in developing areas without widespread Internet and technology access to share what access was available amongst a larger group of people.

The solution we arrived at for that would empower one person who had access to online training to print out that training in a way that would be uniquely tagged (i.e. "watermarked") to that person. Every time this document was shared, the recipient would be encouraged to scan and/or enter the unique code on the document. This would increase the placement of the person who shared it on a leaderboard.

Much of our initial design for these sessions was written on a whiteboard as I held my laptop facing the whiteboard with one hand and wrote on it with a marker in the other hand. Thankfully, I never dropped my laptop during this process (though there were more than a couple of "close calls").

Towards the end of our agreement on an appropriate product to build, we heard back from one of the mentors. They advised us not to use the Visual Builder toolset and instead to try APEX. A set of accounts were given to us with extra system credits and we began looking into this technology. For most of us, this was our first time ever using APEX, which is Oracle's entry in the field of "low code" software development.

The day ended with us having created the required database tables and REST methods to support the generation of the required serial numbers and databasing of information about the content being shared. Not wanting to make these serial numbers too long presented an interesting technical challenge with a relatively straight-forward answer I had not previously considered. I wanted to model this after the serial numbers on US dollar bills, which are essentially a series of digits between 0 and 9 or capital letter between A and Z. I realized that this is essentially Base36 encoding, which I'd not heard of before, but which turned out to have plenty of code readily available on the Internet to "borrow." :-)

Saturday ("Norming")

As Friday night turned into Saturday, we were well underway with build against a solution as shown below...

Sadly, we got a bit of a curveball early in the morning. The feedback from one of the mentors required that we pivot our solution. Essentially, they pointed out that our solution required printers - which are not abundant in the parts of the developing world we looked to serve and, beyond that, also cameras (for our QR scanning feature) and wireless Internet. Also, they pointed out, the idea of achieving top billing on a leaderboard is not a universal incentive to participation, so we needed to look for other ways to incentive participation.

Saturday morning involved a marathon meeting where we evolved our previous solution to retain some of its most fitting idea and add on others. Now we were going to focus on the development of a content curation system. This system supports three unique workflows...

Unfortunately, as we considered all the challenges, we realized it is not possible to design a single solution that satisfies all the possible constraints. In moving away from printed content, we established a requirement for students to have SOME kind of technology - albeit by using APEX, our solution should work out-of-the-box on mobile phones, as we have learned as ubiquitous in the developing world.

It is interesting to note how the results here differed from previous hackathons in which I've been involved. I think it likely that previous teams I've been on would not have caught the disconnect between the "business requirements" and what we were delivering until... well, after delivery. :-). We spent the majority of Saturday in discussions to agree upon an alternative solution - to the point that on Saturday afternoon we wound up doing "mini pitches" of different ideas and voting to see which direction we wanted to go.

By end-of-day in North America on Saturday, we had the completed database tier and REST methods to support the new application, with development on the UI proceeding far into the night in the US and throughout the next day in India.

Sunday ("Performing")

Sunday arrived without any dramatic changes in requirements - hurray! :-). We started with a team meeting where we reviewed the work items from the past 12 hours and assigned team members to attend to the remaining gaps. An important shift in this phase was an increased emphasis in packaging of the final delivery. We essentially wound up with two work streams...

• Technology integration -- a lot of great bits had been built over the last 48 hours and a lot had been learned about APEX, but now the time had come to consolidate and trim out the pieces of the solution that weren't going to happen in the allotted time frame.
• Presentation -- the final requirements for the hackathon required a video demonstration posted publicly to YouTube, an (optional) 8 page document explaining the solution and delivery of the code base.

To the above, I added the need for a LinkedIn article capturing out experiences. Thus my writing to you now. :-)

The Grand Finale ("Adjourning")

By 5 PM, our application was finalized and use cases thoroughly documented. It was time to record the presentation, finalize the document, submit the materials and publish to social media.

You will see in the YouTube video that we got pretty far for the amount of time invested. Whether we win or not, it feels great to have worked in a collaborative environment to make some progress towards achieving sustainability in the 21st century!

Links and Acknowledgements

I have included links to the relevant Github repo below. In conclusion, I would like to take this opportunity to individually acknowledge and thank the members of the Fitch Group team for this year's hackathon...

• Neelima Divi
• Eileen Fahey
• Derek Ferguson
• Rishabh Gupta
• Aleks Hagy
• Rashid Mohammad
• Murugan Poornachandran
• Prem Prakash

Github is at https://github.com/dotnetdevotee/FitchGroup