There are a couple ways to think about Hack4Impact’s mission – an engineering organization that develops applications to help nonprofits, or a social good organization that helps nonprofits by developing applications. Despite the focus, engineering is a crucial part of our organization, and steps need to be taken to ensure engineering excellence within.

What is engineering excellence? Is it perfect code? Is it comprehensive documentation? Is it fully tested applications? I would argue that it is none of these – rather, the only measure for engineering excellence is how well does engineering help us accomplish our mission. To convert this into Hack4Impact’s mission, is our engineering impactful?

Something that I have been thinking about on a national level is how well engineering contributes to our impact for nonprofits. I’ve come to the conclusion that engineering and design prowess should only be a multiplier in our impact (and there’s still a long way to go here). If what we’re building isn’t used, then everything else is extraneous.

Let me put it in some math terms for the nerds like Albert. Our quality of projects should be the multiplier for impact, so lets say quality * impact = total_impact. Say our engineering is top notch, so quality = 20 , but none of our products get shipped: impact = 0. Then total_impact = 20 * 0 = 0.

With this in mind, we should focus from how we can have incredible engineering to how we can make important projects. And remember, things don’t have to change the world to be important. So let’s define some metrics for success.

Metrics for Success

• A complete feature set. The team needs to strike a balance between how beautifully something is done with how fast it can be achieved. Specifically, unreadable code should not be pushed, but perfect code that takes twice as long to write should not be written either. Find the balance between development speed to complete the features (especially P0) and engineering quality.
• Member learning and experience. This is especially important, as many incoming members will be on different starting levels when first working on the project. It is important that members learn things that they are interested in, while contributing effectively to the project.
• Ease of continuation. This is an important question as more of our projects are extending beyond one semester, and new engineers are beginning work in an existing codebase. How fast are they able to ramp up and contribute?