Baby Bookie: Lessons Learned from a (Three-Week) 48-Hour Project
This post originally appeared on Pointless Corp.
Pointless Weekend is a great Viget tradition. A less-great tradition: the team at Viget HQ not finishing our project during Pointless Weekend.
This year, while we successfully delivered a healthy Baby Bookie (and some lame puns) a few weeks late, we were once again bested by the Durham team during the weekend itself. Here are some things we’ve learned about 48-hour projects during our 0-for-2 HQ Pointless Weekends.
Focus on the Dev
Many HQ Vigets volunteer their time for Pointless Weekend. That’s wonderful for team bonding and general participation, but isn’t completely helpful for a 48-hour app.
The Baby Bookie team consisted of:
- Three project managers (including one acting as product manager)
- Two marketing strategists
- Two designers
- One UX designer
- Two developers
- Two front-end developers
- One CEO
While the Durham team quickly jumped into coding, the HQ team spent a lot of time discussing and planning. Because the developers were far outnumbered, the discussion veered toward features and UI that shouldn’t have been considered for a 48-hour project.
Next year the HQ project should be much more developer-focused (without discouraging non-dev participation), as they know best what’s possible in the constrained timeframe.
Keep It Simple
We encourage clients to start with simple implementations and iterate from there. Pointless Weekend is a chance for us to follow our own advice, but with Baby Bookie we instead became our own overambitious client.
Some things we should probably leave out of our next 48-hour project, at least until the basic app is completed:
- Modal windows and pages containing multiple forms—For example, logged-out users can create an account on the same page where they place a bet. That added unnecessary complexity.
- “Weird workflows that don’t work with the technology,” as developer Ryan Foster put it—For example, upon submitting the new pool form, a user is taken to an interstitial confirmation page rather than to the new pool’s show page.
- Pages with multiple states—For example, the pool show page displays slightly different content depending on whether the viewer is a pool admin, a logged-in non-admin, or a logged-out visitor; whether the viewer has placed a bet in the pool; whether the pool is open or closed.
- Overthinking—We imagined most users would belong to only one baby pool, and initially thought it would be odd to show those users a pool index containing just one pool. So we implemented a redirect for when a user who belongs to only one pool went to their pool index. Later, we realized this made it hard for a user to navigate back to their pool from another page.
Chin Up, HQ!
We still had a great time, and we’re proud of how Baby Bookie ultimately turned out. Just as we learn something from each client engagement, we’ve learned something from each Pointless Weekend misfire.
Next year, HQ will be ready to take what we’ve learned and finally create that mythical 48-hour app!
