Reducing Time To Hello World

Neal Humphrey | November 17, 2017

One of the unique elements of the Housing Insights project is that the software developers, data analysts and designers working on the project are volunteers. This is true of all projects at Code for DC and many Code for America brigades, but it’s not a common setup for a tech project. Most successful volunteers end up committing 5+ hours per week for a month or more. In software development, though, even 20 hours is a small amount and it can easily evaporate. When your most committed volunteers only have 4-5 hours/week to give to the project, reducing overhead time of configuration, learning the code base, and deciding what to do really pays off.

'Sprint' for Volunteers: A Software Design Process for Volunteer Civic Tech

Neal Humphrey | November 16, 2017

User input is critical to designing a good tech product - I outlined some of the key considerations in the User Input in Civic Tech blog post previously. Software development has been grappling with this issue for a long time, and there are a lot of techniques out there to help - design thinking, user experience design, human centered design, and the Lean Startup movement are all methods created to solve this problem. These are all powerful techniques, but it can sometimes be hard to turn these concepts into a clear action plan, and especially to manage the delicate balance of how much time to spend learning vs. doing.

User Input in Civic Tech

Neal Humphrey | November 15, 2017

It’s easy to build a website that no one uses. First, you hear about a problem - either something you see in the world, or something someone working in the world tells you about. You say to yourself - “Tech can solve this!” You sit down, draw up a plan, and then start coding. Several short months later, you release your software/tool/website/tech solution to the world, eager for accolades. Then, nothing happens.

Reusable D3 Charts and Launching D3 Boilerplate

Neal Humphrey | August 16, 2017

Lately I’ve been working on making D3 charts more reusable. In particular, I wanted a structure that I could use when I started any new chart that would naturally lead to an elegant code design and so that I wouldn’t need big code refactors when I (inevitably) wanted to add features like resizability. This mostly developed during my work on the Housing Insights project. John Osterman and I worked on a few permutations and settled on a structure that I think works well. I’m pulling this out into its own open source project because I think it has a lot of potential for making D3 charts easier for future projects and other developers - I’m launching this as D3 Boilerplate.