National Day of Civic Hacking

Saturday, I went to my first-ever hackathon: Code for Denver's event for National Day of Civic Hacking. Ostensibly we were working on the low-income housing challenge suggested by the national organization (although one group was specifically working on the EPA/waste-visualization challenge). While I'm not sure about how successful the development process was, it was a great learning experience for me and helped me in my quest to understand how code/programming can be a social good/helping profession--that failure of imagination I think I've mentioned before on here.

So, being my first experience, my general takeaway: very overwhelmed, and also, I should have prepared differently (could have used more info from our host location, but I could also have done more with the national site to prepare: they had a lot of really neat ideas up there).

One thing my location did that I think was a great idea, but that didn't work out so well in implementation, was having a representative from an area nonprofit (MetroCaring) come to talk about his organization's needs. I think this was a really good idea, but a couple of problems: first, they don't actually work in housing (but they do refer people to other agencies that do, so there was at least a related need), and second, the rep had to leave pretty much immediately after his statement, which means that as process questions came up, we would get stuck trying to guess how they would use various features, and which ones most closely met their needs.

We ended up having several groups working on various projects: I chose to work in the group dealing with MetroCaring's case. (Other groups had already-in-process projects, such as data mapping or....data visualization. Everybody likes data visualization, I guess, but that brings me to another point, which I'll address below: what are the limits of coding application to actual real-world problems.) Our group was about evenly divided, with four developers and three new-to-tech types. I ended up being the proxy-stakeholder, because for the morning session, at least, I was the only person with any experience working in nonprofits. (In the afternoon, one of the developers had experience working with emergency shelter nonprofits, which led to a bit of a midday pivot from facilitating access to vouchers to facilitating access to emergency shelter.)

But what was surprising to me was that one developer in particular kind of hijacked the project because: a) he knows better than nonprofits (since folks in nonprofit work "benefit" by the problems continuing, in that they can keep their jobs), b) he was bound and determined that we could find a way to develop a product that paid for itself, and even made a profit to spin off its own "descendant" projects, and c) he was wedded to using two proprietary products, even though it meant changing the problem we were solving because of limitations in those products. So instead of generating a tool for tracking voucher availability that would be update-able by any disbursing agency and check-able by any referring agency, he (and I say he, because really no one else could be involved, as nothing he wanted to do was delegate-able) created a sort-of-working zap that would call an agency when someone updated a particular spreadsheet, and ask that agency to call them back with a number of available beds.

Difficult personalities aside--because those are omnipresent--it was not exactly a success, but the rest of the group did at least have some interesting discussion and maybe made some progress toward defining a different version of the project, working from the United Way's 2-1-1 resource. One of the developers found a good data source in a non-intuitive place in 2-1-1; another scraped it, with resultant JSON that could potentially be used for a more accessible data source, rather than duplicate-calling the same shelters, depending on how many of the entries were up-to-date.

In the day-end wrap-up presentations, the other groups had made some progress on their data visualization projects, whether it was triangulating average housing cost, access-to-transit, and access-to-schools in a single map or visualizing waste flows.

But what is most interesting to me here is how few of the projects seemed actually to meet a need, rather than just generating something that looked cool. One of the mapping apps is intended to help folks determine where to focus their housing search, based on where they work, where their kids go to school, and where they can afford to live, in a mobile-friendly/responsive format. So that could be useful. The other projects really didn't meet a concrete need, as far as I could tell, although of course, more information shared with more people is still good.

So my failure-of-imagination, in reference to being able to figure out how programming can really help people, in the sense of a public good (like the helping profession post from a few weeks ago), continues. The hackathon experience was a good one, even though we didn't get much actually accomplished--I think it pointed to ways tech can and cannot help with actual problems.

And then this morning, the weekly Nonprofit with Balls blog post: Hey tech people, stop thinking only you can save the world. And it is just really good. My most-favorite part was about how a tech-can-fix-it-all!-approach can lead you to ignore the root problems of social inequity, for instance. It came up at the hackathon: we aren't going to solve homelessness. We aren't. But maybe we can make a tool for helping folks get access to vouchers (since this was before the pivot...). One of the attendees wanted to work on a mapping tool for low-cost properties that could be developed into low-cost housing, so that would be a tool for increasing supply, and thus actually addressing the problem on the ground, but there is (as yet) no way to code actual living spaces, and frankly, is unlikely to be. (I dunno, 3D printing?)

I don't really have a conclusion. I'll keep exploring. I love some of the National Day of Civic Hacking's ideas, and I love what Code for Denver is trying to do. So I guess it's all about tempering expectations, and realizing that data visualization doesn't actually solve everything.