Software Engineering, as a discipline, is just as much an art form as it is a science. While there are rules that govern the world of computing the biggest limiting factor is our own imagination. As professionals in the corporate world, all too often we are constricted by the blinders we put on ourselves.
The biggest self-imposed blinder is limiting ourselves to an artificially narrow view of what is possible. We implicitly categorize potential future paths as impossible because they are too hard, too expensive, or would take too long. At one point in time we may have said, “wouldn’t it be cool if…” but the reality of getting there raises too many questions with unknown answers and complications so we quickly rule it out, saying, “We have a business to run…”, “I have this KPI to meet…”, or “This is too risky…”.
We wisely keep these improbable ideas off our roadmaps because we shouldn’t frivolously fritter away our time. If we chased every pipe-dream we’d deliver no value to our customers and fail as a business. Staying grounded in practical roadmaps is also crucial because as engineers it is incredibly fulfilling to see real and tangible results for our labors. All of that being said, a healthy company should always be looking for ways to take a significant leap forward. By challenging our assumptions and making the impossible possible we can achieve greatness.
At ShopKeep we adhere to lean software development best practices, which helps us focus on outcomes instead of pre-baked courses, but there are times where even that is insufficient to spur the level of innovation we need.
Enter the CodeSmash. A CodeSmash is ShopKeep’s hackathon. We use our hackathons to exercise our artistic, innovative, and passionate side from our more rational, cautious, and disciplined side. We deliberately drop our blinders. There is nothing impossible in a hackathon. No idea is too scary, too ridiculous, or too big. To encourage as much creativity as possible we brainstorm heavily ahead of our CodeSmash. Employees from around the company are encouraged to submit ideas to improve our products, improve our processes, replace technology, adopt new technology, or to figure out how to get a previous hackathon project production ready. We tend to have significantly more ideas than we have people to work on them.
When a CodeSmash begins we let teams form organically. People work together because they are united towards the same passion for a project idea, they want to learn a new technology or discipline.
As a reality check, there is only one rule during a CodeSmash, which is that time-sensitive production support issues come first. But other than that, teams are free to build, imagine, innovate as they see fit.
Over the years I’ve been asked by people why we hold hackathons. They want to know about things like what is the return on this investment of time and resources? It is sometimes hard for those outside product engineering departments to wrap their head around why we do hackathons, but the best analogy to help them understand is that hackathons are self-directed R&D in a fixed period of time. It is very much like Agile software development. where we fix time and cost, and let the scope vary. In this case we are fixing the time and the cost and we leave the scope to the entire development team. The ROI is hard to measure because there are so many benefits, but they are more nebulous than the typical product driven markers we usually use to measure our progress. The benefits fall into three categories: inspiration, innovation, and invention.
Inspiration – Each person is passionate about an array of different things. Letting them follow their passion leads to incredibly high quality work but it isn’t always possible during their everyday because their passion may not align 100% with the work that they need to do for their teams. During a hackathon we encourage people to choose projects that inspire them. Getting the opportunity to feed that wild inspiration within the context of our company’s work helps them see how they can find inspiration in more mundane work, or how they can shape our work to better reflect the ideas and technologies they are inspired by.
Innovation – Since time is very limited during hackathons, teams must be resourceful and creative. A roadblock in a hackathon can be the death knell for a project, so if you want to make the impossible possible in 1.5 days you’ll need to be innovative. That innovation doesn’t end with the CodeSmash award ceremony, instead, it bleeds into our regular work and helps us be more imaginative problem solvers the rest of the year.
Invention – So many great ideas at ShopKeep have started life as a hackathon project. New technologies have been adopted. New products have been started because of experiments during a hackathon. Scary roadmap items that were over a year away have been reimagined and completed during hackathons. Our CodeSmashes breathe new life into our products.
Oh yeah, and they are really are fun.