Lessons Learned from GiveCamp 2012

By Matthew Seeley

The pressure and constraints of a fast-paced project at an event like GiveCamp can provide perspective on some important parts of the development process

06 Nov 2012

The Grand Rapids GiveCamp is always a learning experience for me. For those who aren't familiar with this event, GiveCamp gathers a large group of talented software professionals to volunteer their time and energy to assist area non-profit organizations with technical solutions.
This is my second year volunteering for the event and working with the Grand Rapids Chapter of the American Red Cross. This year, we created a inventory tracking application for the Red Cross to manage resources across a region, to help them better respond in a crisis. One of the key features of the application was a heavy emphasis on mobile-first development -- Red Cross volunteers often interact with their resource inventory in the field, so the application had to be designed responsively so that their volunteers could ensure its data accuracy using a wide variety of mobile devices that happened to be available to a volunteer at any given time. GiveCamp places extreme pressure on the project and its team. The amount of time, the number of volunteers, and the resources available constrain the options available for a project, which makes executing at a high level a very difficult challenge. As an event that relies on skilled volunteers, GiveCamp is often heavily focused on volunteers giving to the non-profit. However, I've learned a few valuable insights while working on projects within the pressure and constraints of GiveCamp:

Gather requirements and make plans before the event

The weekend of GiveCamp is busy and hectic. Most of your team's initial energy and enthusiasm is likely to occur during the first night. Be sure to have a plan organized before this occurs, so you are able to maximize the momentum.

We met with Chip Kragt of the Grand Rapids Red Cross a month before GiveCamp, and spent time with him once a week, each week, to walk his project through a lightweight design process. Using this time, we were able to break his project out into individual, small pieces of work, and then prioritize them based on his organization's most important needs.

Make sure to document this activity as you go along. Don't document everything, instead, keep it light, well organized, and filled with the key pieces of information needed to continue. People will likely be needing information all throughout the event, and maintaining a digital, centralized location for this is invaluable. I found using GitHub Pages and Wiki to be very helpful for this task. It also allows offsite work to happen (should that occur), and helps future developers who may come in later to understand the vision of the project.

Guard your scope and watch the clock

Excitement will be high during the weekend, and as you and your team build the software, excellent ideas are bound to arise. Often, these features will be "cool" or "flashy" features that are fun to work on. Be flexible on your roadmap, but be realistic in your assessment of what you'll have time to deliver. Above all, the goal of the weekend is to deliver useful, functional software for your non-profit to solve *their* need.

Have an exit strategy before you begin

This is tricky. Your team has poured a lot of time and energy into delivering software to a non-profit. The final demo happens, and everyone's proud to hand the project over to a client.

However, in the rush of GiveCamp weekend, it's likely things were overlooked. There may be bugs or issues in the software, or features that you wanted to get done that had to be dropped to make the deadline.

When meeting to make your plan, before GiveCamp begins, discuss the handoff with your non-profit. Does their organization have the internal technical capacity to handle something like this? What kind of follow up are you planning on offering? Have you explicitly informed your non-profit of these plans?

Running through the plan after GiveCamp is often more important than the plan before, and will help your team hand off a project responsibly. Poorly created, or poorly maintained software is often a larger burden on an organization than no software at all. Planning this before you start helps ensure that both the volunteers on the project and the non-profit have clearly defined similar expectations on what will be delivered and what happens to it after the event.
Grand Rapids GiveCamp 2012 was an exciting, energizing event. I'm proud of our team's work on this project, and the help it will provide to the Red Cross. If you're interested in learning more about this event, visit http://grgivecamp.org/.

About the Author

Matthew Seeley
Matthew Seeley

Matt has been developing software professionally since 2007. His experience runs deepest in Ruby, but his toolbox includes a range of other languages. He takes pride in his holistic approach to software, which enables him to anticipate and address issues before they arise.