We have always had the mentality at Socialize to not only do our best to test production products (especially critical ones) with coverage from an engineering perspective but more importantly understand that having information and transparency into general metrics within the company can keep each employee and manager from having to second guess themselves or look over their shoulder when pushing forward on objectives. With that in mind we created an in-house open source project (https://github.com/sshadmand/Team-City-Monitor) that takes our TeamCity continuous integration builds and pushes them to a heads up display to monitor builds, tests and statuses of support tickets etc. We have also utilized Splunk (http://www.splunk.com/) to create dashboards of request logs to monitor our products usage, response times and general performance, as well as other app related usage statistics.
Now that we are part of ShareThis we were curious: would it be useful to have a single dashboard system/interface that took in disparate pieces of data from every department and city in the company (from the various CI systems and repos to sales, forums and marketing) and displayed it on a single rotating dashboard at every office? We have also wanted to rebuild the original CI heads up display we are using as it has become a bit of a Frankenstein over the years and would not be easy for others in different departments to augment it. With that a hack-a-thon is where we ended up. Here is a bit about what we did , how we did it and what we learned.
Steps we always take when doing a company hack-a-thon:
1) Start with a google doc. It is easy to share, collaboration is real-time, and it is persistent for review or reference down the road.
2) Create a mission for the day. What do you want to leave with. Often times products don’t get complete within a single day and that can make a team feel discouraged and unfulfilled. The baseline goal of every hack-a-thon you participate in is to answer a few question, create some certainty around decisions, and learn something. If we are lucky we will have a working product or at least a proof of concept. Of course it is important to push through the hack-a-thon yearning for a completed project, as that forces you to cut extraneous features and find the MVP in as efficient way as possible, but that doesn’t mean you should forget all the other goodness that comes along the way.
3) One way to always be sure you are walking away with value, questions answered, and learnings is to keep recording what you do and the decisions you make throughout the day. Without it you will most likely walk away feeling like nothing was accomplished (or simply not realizing just how much WAS accomplished) if you don’t have a shiny completed toy. With it you can see and re-use all that you learned along the way.
4) We often create 1 day hack-a-thons. It is enough commitment to get things complete and learn, but not such a large time commitment that people will bail and/or have difficutly coming together on a schedule.
5) Write a blog when you are done. It is one of the deliverables that no matter what you end up accomplishing there is something being pushed publically. Win/win.
6) Create a schedule after the mission is agreed upon and always record what time your cut off is for each time/milestone. For example: “Okay let’s talk about the mission for 10 minutes and then push to start executing by 10AM!” If you slip a bit on your time update the schedule and try not to let each milestone slip too far. It is always good to know right off the bat when your hack-a-thon should start and finish. All the other dates and moments will fall into place as you start chugging along. We usually don’t create more than one milestone time ahead. Over scheduling is a waste of time and will be scrapped more often than not. True product development goes where it needs to as it needs to.
7) Always end with an introspection, a conversation, and go over what went wrong and right. Many times people have learned things separately from one another and this helps tie the day together in the final act if you make sure to sit down and create conversations around the project. It’s amazing how easy it is to forget what you have learned or overcame when it is locked away in everyones head.
That being said, here are some snippets from how today’s hack-a-thon went as noted in our doc:
This is our table of contents that was generated throughout the day. Each title is a check in time and or objective/milestone. We record it as it happens and update it if things slip or change.
It’s really hard to capture in a final doc or snap shot, but eahc of these section are hashed and rehased collabortivly to work your way towardsthe finish line. It is tantamount to how a newly forming river breaks through a muddy hillside on a rainy day:
Here you can see us starting to get in the weeds and verifyong data is what we think it is and tools we wanted to use work the way we want.This isn’t always the case, but for this hack-a-thon there was an effort to not code as much as possible where in other cases the hack-a-thon is to specifciallybuild a proprietary peice of software. You can also see that we have added video, pictures, and links to not only share content that we find for collboration but also to capture the fn and envirement we are participating in. :
As the day moves on we are find our selves burning through time and not getting the results we wanted. What is great about a one day hack-a-thon is it re-enforces the concepts in your head like fail quickly, ieterate on an idea and sometimes just scrap something if it isnt working instead of forcing it:
Here is what our v0.1 Dashboard using Dashing looks like with a couple Jenkins based builds and a SalesForce data query result set:
All in all it was a fun project and hopefully the beginning of a tool that can be used at various of the corp sites. If not we learned quite a bit and exercised our product dev muscled a bit. Definitely check out Shopify’s Dashing project (http://shopify.github.io/dashing/) it is pretty cool and easy to use. Also let us know what you think, or if you have any other best practices you have found that work great for you.