There was one part of being a technical mentor at a hackathon-like event that I wasn’t expecting: there wasn’t all that much code.

I was recently asked to be a mentor for Code For Philly’s Civic Engagement Launchpad (CELaunchpad) since I’m a professional software engineer for PromptWorks, a custom software consulting company here in Center City. Code For Philly builds some great projects for the community, so I thought I’d get involved. By the time I arrived, representatives from local government had pitched their ideas to the community and teams had formed based on their shared interest in a given project. You can read a summary of each project here.

As a mentor, I was tasked with helping each group to analyze the problem, devise a solution, allocate team members for different tasks and implement it. Each mentor came with their own set of specializations: project management, software development, etc. Mentors who specialized in software development focused their effort on helping teams verify their assumptions, ensuring that their project could be backed by a credible and available data source.

Teams had varying degrees of technical experience. My expectation was that the room would be filled with software developers, so I was surprised to find that nearly half of the people I met were non-technical. So, if you want to support the mission of Code for Philly but you don’t think you’ll be able to contribute due to lack of development experience, think again!

CELaunchpad was heavily focused on planning.

Often in a hackathon, you have 36-48 hours to make something you can demo, even if the code is cobbled together and the design is half-baked. It can be pretty frustrating for someone who’s accustomed to developing apps thoughtfully and carefully. One of the main differentiating points of the Launchpad is that there is more time to plan and design a project.

Focusing on planning is a great idea … in moderation. Initially, teams will need to understand the target audience for their software project. Then, teams will need to decide which features they expect to implement. Finally, teams will need to analyze their bench strength and allocate work with regard to each team member’s area of concentration.

This is when teams should have stopped planning and started prototyping. I saw several teams spend their entire day putting stickies on the whiteboard, and while it was initially very useful for the teams to come to a shared understanding of what they were trying to accomplish, it eventually became repetitive.

Instead, this time could have been spent prototyping as a team. One of the hardest challenges in software development is estimation. The difficulty of estimation has a direct correlation with the number of unanswered questions. Prototyping always gives me a sense of clarity on what it will actually take to complete a specific feature.

I get it — planning is comfortable! Everyone is sharing ideas and collaborating like a pro. You’re typing up the most beautiful meeting notes anyone has ever seen and generating a mind-blowing list of cool features.

Throwing around code in front of strangers — that’s a different story. It’s weird. You might make mistakes, especially if you’re somewhat green or you’re not sure if you’re taking the right approach. You don’t want people judging your work when it’s not ready for them to look at.

Planning has diminishing returns.

Using code to build a functional prototype is how you know what’s working and what’s not. In essence, you’re using code to help you think through (and solve) the problem. The goal of planning is to get enough outlined for a shared understanding among the team, not to specify everything ahead of time.

Teams get more bang for their buck when they plan just enough to start coding and then iterate.

We see this desire all the time in our consulting business: clients want to know exactly what the final product will be like before they commit a single dollar to development. The problem is that planning has diminishing returns. No matter how much you plan, once you have a working web or mobile app in front of you (or a user!), you’re going to see how it should have been made differently — sometimes radically so. Teams get more bang for their buck when they plan just enough to start coding and then iterate.

How to plan just the right amount

Whether your project is a Code for Philly CELaunchpad project, a personal project for fun, a $50,000 startup or a million-dollar enterprise software project, here are four tips to help you plan just the right amount and then get right to iterative development.

1. Define and articulate your goal.

Use the planning process to collaboratively define what you want to accomplish with the product. The strategy and tactics you use may change along the way as you test assumptions, but the end goal should be the anchor in the iterative process. The entire team should be able to articulate the same shared goal before you get into development.

Pro tip: Most people think they’re on the same page but may have dramatically different interpretations. Make your shared understanding concrete by putting it on paper. At PromptWorks we challenge our clients to agree on a concise elevator pitch or walk them through exercises that define the “who, what, why, but” of the product and what the product isn’t (aka. the “not list”).

2. Know who the users are, what they need, and how your project meets that need.

The first rule to building a successful piece of software is building to meet a need. It sounds simple — and it is — but too often products end up missing the mark. Products become over-designed with the latest trends in the industry because it’s a more interesting process for the developers and designers. Know who the users are for the end product and understand (and build) for their needs.

Pro tip: You are not the end-user. Don’t design for what features you like and find intuitive. Make the effort to talk to users and if you can, show them a visual sketch of your idea to help them give you better feedback.

3. Discover just enough user requirements to outline your architecture.

You need to know what you’re building to choose the right tech stack, but you don’t actually need to know very much. Just adopt a tech stack that’s in the right ballpark and you’ll be set. Thinking you have to know every requirement so you can pick the perfect database or debate which queueing technology you should choose is a supreme waste of effort. When you’re first starting a product, you don’t know enough about it to make those kinds of decisions accurately, so you should focus on using the technologies you know to make working software quickly.

Pro tip: Focus on solving the business problems and you can bend pretty much any tech to make it work for now. It’s not so hard to migrate data from one format or system to another or even to re-implement something in a different framework. Once your app is successful you can perfectly align the tech stack.

4. Know your resources and decide on tradeoffs.

I saved the hardest for last: Making tradeoffs is the least-fun part of building something. Coming up with ideas for features and functionality comes naturally, especially when working on a team of smart, thoughtful people. But resources will always be limited in some way. For companies it’s budget, and for volunteer teams it’s time and energy. As a team, you’ll need to decide what are the absolute fewest (and most important) features that can be built in order to make a minimum viable product (MVP). That means knowing what your resources are, as well as the limits to those resources, and making tradeoffs to get a functional MVP. Keep a long list of features and functionality and rank it in order of importance. Then start tackling the list from the top and strictly work on it in priority order.

Pro tip: Software is never really done. Your MVP is just the beginning of iterating and refining the product. With each new release, that prioritized list gets a little shorter. One of the best parts of making your project open source is that you can have an ongoing to-do list that others in the development community can help with.

With these four things in mind, your team will have a unified vision for the project, and you’ll be able to adapt when you hit a bump in the road.

I’m looking forward to continuing to work with the CELaunchpad groups and helping them make civic engagement software that has a positive impact for citizens of Philadelphia.