I survived and finished my very first company hackathon event as an active participant.
For those of you unfamiliar with hackathons, they are events where techies get together to work on a team agreed project over a period of time (usually around a week), in an intense, caffeine and junk food fueled marathon of dedicated software design and coding.
At the end of the hackathon, teams gather together to present their final project deliverables. A panel of judges are usually assigned to review the projects and often award prizes to the project(s) deemed the best of the best.
I have to admit that I never really took hackathons very seriously. My thought process behind my “meh” attitude towards hackathons went something like this … you work at a McDonalds all day, the last thing you want to see when you get home is a french fry.
But after a lot of prodding and convincing from my manager and his infectious enthusiasm and decision to join our company sponsored hackathon event himself, I decided to sign up at the last minute.
My manager and I were in a little bit of a disadvantage because of our lateness; a lot of the other registrants had already pre-formed teams and came up with their product idea. The hackathon rules stated that a team must comprise of at least 4 members, but so far, it was just my manager and myself.
We scrambled around, asking other coworkers around us if they had already joined the hackathon. We didn’t even really have a well formed idea for a project … just the seed of an idea.
I’m not sure who suggested it first, but we started free associating ideas and we began talking about how difficult it was to find a person with specific SME (Subject Matter Experts) skills at our company.
A SME is any person with an area of expertise in a specific business domain or technical domain.
For instance, a person could have SME skills in using Salesforce. Or technical expertise with Oracle databases.
I often run into problems in my day to day activities where I get stuck on a certain issue, and I don’t have the expertise needed to solve that problem on my own.
Maybe the database for one of my applications is getting bogged down by its sheer size, and I need a database optimization expert to help me figure out ways to speed up the database query performance.
Or perhaps I need some help analyzing some sales related data, and I need the assistance of someone with expert marketing and analysis skills.
Believe it or not, with all the technology available at our disposal in modern IT organizations, it can often be challenging finding the right person with the right subject matter expert skills.
The issue is there’s TOO MUCH INFORMATION at our disposal! And often scattered across different and disconnected databases and systems, different geographical regions and in different data formats that cannot “talk” to each other.
Sure, you can ask around, talk to your coworkers, and you’ll EVENTUALLY be pointed in the right direction.
But wouldn’t it be great if you could SEARCH for the subject matter in a tool, and get back a list of employees with the most relevant skills?
BAM. Our hackathon project was born!
PROJECT DESCRIPTION
My hackathon team ultimately came up with the name “SMEagle Eye”, a Google like, web based search engine that would dig through our official company wiki database, Confluence, and display the most recent search results.
Why a wiki? We happened to discovered that Confluence exposed a set of public REST APIs, that allowed us to query its database via standard HTTP calls, and get back a resultset in a JSON data format (a popular and standardized data format especially well-suited for modern software applications that need to communicate with each other).
Whenever a company employee writes a blog post, some technical documentation, or any other type of helpful information, Confluence stores that information, along with the employee information, into its system.
It therefore stands to reason that a person who writes and stores information about a particular technical or business related topic into Confluence, would be a POTENTIAL SUBJECT MATTER EXPERT.
So that took care of our database needs for our project.
What about the technology stack?
Pretty much any tech stack that can make simple HTTP network requests and return a standardized data format like JSON or XML, would serve our project needs.
My company has quite the cornucopia of tech stacks, .NET, Java, Android, iOS, LAMP, and MEAN.
As a Microsoft developer, .NET would have been more than adequate to serve our project needs.
But in my opinion, hackathon events are designed to ENCOURAGE techies to get out of their comfort zones. TO BOLDLY GO WHERE NO MAN HAS GONE BEFORE…well…you get the picture.
I wanted to get out of my own Microsoft comfort zone and choose a different technology stack to implement our project.
Over the course of the past couple of months prior to our hackathon, I’ve been immersing myself in the MEAN stack. The MEAN technology stack is comprised of 4 major components.
M: MongoDB, an open source NoSQL, object based database with native JSON data format.
E: Express, a routing engine that directs web page requests to the correct request handlers on the web server.
A: AngularJS, a client side library that provides rich desktop software like functionality in a web page.
N: NodeJS, a javascript based server side framework to handle the web requests from the browser…database interactions, business logic of the application, etc…
The company hackathon would be a great way to prove that the MEAN stack could be a great alternative technology stack to implement our project!
So five days for the hackathon … four days to design and implement the project, and the final day for the showcase presentations.
Here’s how it went down …
Day 1 – “The Meet and Greet”
“It’s a 106 miles to Chicago, we’ve got a full tank of gas, half a pack of cigarettes, it’s dark and we’re wearing sunglasses.” – The Blues Brothers
The first day was about meeting the rest of our hackathon team and getting all on the same page about our project goals and team assignments.
The team consisted of myself, Randy Sapitan (my manager), Augusto Maza (fellow coworker) and Dave Sherman (DevOps Administrator).
We treated the week like a little mini Scrum sprint. The first day was our mini sprint grooming/planning session. We scoped out each of the sprint stories we would need to implement, and divided our project into three main parts:
1. UI/UX – Creating the user interface and user experience workflow
2. REST APIs – Exploring the Confluence wiki API for our data needs
3. Wiring up the UI to the API.
Our team found an empty conference room, and began whiteboarding out the user interface screen and all the UI interactions.
We split up the work of researching the Confluence REST APIs and their capabilities among us.
What we ended up with was a high level design document that described our project, its functionality, and who would end up taking up which task.
If you ever want to know how the “sausage gets made” in the software engineering world, this is pretty much it!
Day 2 – “The UI/UX Workflow”
The second day was spent working on the UI/UX design. I often like to start with the user interface. It’s easier to capture the essence of a software application and its required functionality when you can VISUALLY see what the final screen(s) will look like.
Apple tends to design their software the same way, starting with the user interfaces first. They’re all about a polished end user experience, so they naturally gravitate to the visual look of a product.
The page would look and behave pretty much like the Google home page… a simple textbox to input your keyword search and a button to initiate the search. When the search results came back, they would appear in a data grid format below the search box.
We used AngularJS to handle the client-side scripting needs of the user interface and the Twitter Bootstrap library to give the screen a little bit of UI polish and pizzazz.
Day 3 – “Building the REST API”
As I mentioned before, we discovered that Confluence, a corporate wiki system, allowed for custom applications such as ours, to mine their data, via HTTP network requests.
We assigned each team member, including myself, to dig through the API methods, and figure out the best APIs to meet our data needs.
We used tools like Fiddler and the Chrome developer extension, Postman, to make sample HTTP requests against the Confluence system and see what kind of data results would return from our requests.
We ended up finding a title based REST API method to allow for a keyword search of the title of all Confluence wiki documents.
I created a REST API in NodeJS to call the Confluence REST APIs, and return the results back in JSON.
Day 4 – “Wiring up the UI”
With the user interface screen and REST APIs ready to go, now we had to wire them up together to give us the final application functionality.
The UX flow of our application was pretty straightforward.
A user would type in a phrase into the search input box. Something like ‘Oracle’. Or ‘Salesforce’. When the user clicked the “Search” button, our SMEagle Eye application would make a REST based HTTP call to our REST service on our web server, and make a call to the Confluence based REST service which would take our keyword phrase and query the Confluence database and bring back any search results back to our screen.
Day 5 – “Last Day: It compiles, ship it!”
The big day. Randy would handle the actual presentation and I would handle demoing our application.
We practiced some dry run presentations in the morning before the actual presentation.
I tested the application and made sure we used specific search phrases that guaranteed the results we needed for the demo.
We were given five minutes for our presentation and it thankfully went off without a hitch. The application worked and Randy deftly explained the usefulness of our tool.
Mission accomplished!
RETROSPECTIVE
This was the second hackathon event which my company, CDK Global, sponsored. The first year, there were a hundred participants.
This year, it was DOUBLE.
It was an AMAZING turnout. Most of our company summer interns participated and there was an incredible variety of projects. One team’s project used our internal wifi network to map a person’s location within our building structure.
Another team, created mostly by summer interns, was an iPhone app to help incoming new interns get acclimated within our corporate environment and allowed interns to chat with each other, leave messages, and provide company resources directory assistance to various departments.
What have I personally observed from our hackathon?
There’s been a lot of stories in the news lately about the lack of minority and gender diversity in the employee ranks of Information Technology.
Which, no doubt, is a real concern that companies need to continue to address.
But looking out at the crowds of young men and women who participated in the hackathon, I can honestly say things seem to be heading in the right direction … more women, more minority participation. If hackathons are any indication of increased diversity participation, I’m hopeful it will improve out in the real world.
From a technology perspective, it’s easy to see how much opportunity exists to improve processes and efficiencies in the corporate environment.
It’s common to see siloed systems and environments in most offices. But there’s no EXCUSE for it. It’s easy to CONNECT systems together, with the help of RESTful APIs and services.
Our company, really ANY company, needs to constantly think of ways to make data and systems work more closely together.
All in all, it was an exhausting but REWARDING experience. For the better part of a week, it was nice to be able to concentrate on working on pure software design and coding and not get distracted by meetings and other company events that can pull you away from the actual act of software engineering.
It reminded me of how FUN it was to be a software engineer, during my early phase of my programming career.
Will I be at the next company hackathon?
Ask me after a 72 hour nap.
