Why the Agoric Team Spent a Week Eating Our Own Dogfood
By: Michael Jablon
Tags: Hackathons, Coding, Startup, Smart Contracts, JavaScript

The whole Agoric team took a week off work. Not because of the pandemic. Not for vacation. Not for a mental-health break. We took off work to take part in a hackathon. Specifically, an internal hackathon. At Agoric we develop tools (called Zoe and ERTP) for building and trading digital assets. We recognized that doing our own internal hackathon where we were the participants, rather than just the sponsors, would be beneficial for various reasons, among them:

We’d learn what our users experience with our software tools — because we’d have to use the tools ourselves. We’d all get better at our tools — because we’d take a break from being individual specialists and for the week be a team of generalists. We’d improve our offering — because everything we learned would be funneled back into what we do, not just into the tools, but the user experience, the documentation, everything.

The Care and Feeding of Software Development

There’s a term in product development where you “eat your own dogfood.” Amazon employees buy products online to understand and improve the user experience. Microsoft employees use beta Word, Excel, and PowerPoint to make sure the suite is truly enterprise-grade. Apple employees use iPad Pros to make sure they can really serve as desktop replacements.

Our internal hackathon was a week-long event where the entire Agoric team, and a few invited friends, participated in a deep dive into building DeFi (decentralized finance) and other solutions that benefit from our smart-contract platform (Zoe and ERTP). Our tools dramatically simplify the development of smart contracts. We help developers write contract constructs in just a few lines of code.

How to Prep for an Internal Hackathon

The concept of an internal hackathon isn’t just applicable to us. Certainly any software company could benefit from it. In addition, though, if you’re in another industry, like publishing, or healthcare, or education, you still might be able to adapt the concept to your own operations.

Set goals: We knew what we wanted out of this. We wanted everyone on the Agoric team, which numbers a little more than a dozen people, to build and demonstrate a new smart contract on our platform, specifically using Zoe and ERTP. There’s an important “rubber meets the road” internal understanding you get when you actually get something working. Our secondary goal was to implement examples that show new possibilities for our system. Plan projects: Most hackathons involve a set of challenges, or projects, that the participants select from and then try to accomplish. Some hackathons are more self-directed than others. We came up with projects that exposed the team to topics we wanted everyone to have familiarity with. We also use the challenges as ways to produce proof-of-concept examples in new areas. We did several rounds of brainstorming, in which various team members contributed. Having criteria was helpful in, for example, filtering out projects that, while interesting and helpful to ongoing engineering, didn’t provide the learning we wanted. Pre-select teams: In our case this involved a mix of internal and external participants. In regular hackathons, the teams are largely self-selecting. We had some self-selection, but also balanced skills so that every team had its share of engineers familiar with the part of the system we wanted to learn, and the non-engineers could learn and get assistance. Don’t bother with competition: There were no prizes for our internal hackathon. The point wasn’t for anyone to get anything done first, or to judge one project versus another. The goal was to play in the sandbox together, and to learn together. Invite outsiders: It can help to have an outsider or two on each team. This brings in fresh ideas, and keeps work colleagues from falling back on familiarity and shorthand when communicating. These were “inside outsiders,” meaning they were already familiar with what Agoric does, and didn’t require time-consuming handholding.

It’s Not a Sprint or a Marathon

There’s a term in software development for a “sprint,” which is a set amount of time (a week, a month) during which a team iteratively and rapidly improves upon something with the goal of finalizing it within the product (i.e., shipping the upgrade). It’s important to understand that an internal hackathon is quite different from a sprint. A sprint is a means to achieve a development milestone expediently: You’re building the product. In an internal hackathon, we weren’t building the product. We were using the product.

What Happens in an Internal Hackathon Doesn’t Stay in an Internal Hackathon

Our internal hackathon ran the week immediately after the Fourth of July holiday break. We explored essential concepts that make Agoric tick, like governance, voting, and lending, among others. After the hackathon was over, we gathered to celebrate what we’d all done together, and then did the all-important post-hackathon work, much as we do after regular hackathons. This involved interviewing select participants to gauge their experience and collecting feedback accumulated during the process. This work helped us to delineate product needs and to prioritize development opportunities, all in the interest of helping our actual users to be more successful and to achieve their own goals more quickly.

. . .

Thanks for reading. You can join the Agoric community on Twitter, Telegram, and LinkedIn, subscribe to our monthly newsletter, and catch us at upcoming events.