Sensibly Thinking About Where Technology Ends And The Human Part Begins With APIs

Our team at a hackathon I’m participating in this week is working on a data aggregation tool for helping merge multiple hurrican shelter data sources from Irma in Florida. While the need for the data is winding down, the use case for the tool could be something that lives on, and could help communities in the future. This projects aggregates multiple data sources for shelters from FEMA, municipal, and sources pulled together by volunteers. Our team is focused on aggregating, and doing as much heavy lifting to automatically merge and cleanse the data as they can, but then at the right moment render it for humans to step in and finish the work.

I was impressed with the balance struck by the team. Knowing where to apply technology, and when to rely on humans. The problem of merging open data from multiple sources is a big and complex one. It is one that I’ve seen many technologists think they can step up and solve simply with their tech toolbox, no humans necessary. Our team quickly saw the scope of the program, discussed at length about what they could accomplish, and what they couldn’t accomplish, then got to work in the code to deliver the functionality, but then also developed a web interface to allow humans to step in at just the right point. Striking a balance between the human and technological aspects of doing this–which is what the Human Services Data Specification (HSDS) is all about.

I know there is a significant amount of information out there about User Experience (UX), and also increasingly Developer Experience (DX). However, I think skills to know where to apply technology, and when to step back from using it, and focusing on augmenting, empowering, and putting the humans in charge are seriously deficient in our sector. I regularly encounter developers who think that technology is the solution, and humans are the problem. This contempt always degrades the amount of investment in the user interface portion of the question, and will also shift the developer experience portion, ensuring the API speaks to the technological needs, and not the human needs. This isn’t how all of this should work. It isn’t about the tech. It is about what the technology does for humans, not the other way around

The balance of API backend to human front end on this week’s human services hackathon was refreshing to see. Early on I saw the team leaning towards trying to merge, clean up, and solve all the data problems in the code, and I was a little concerned. However, by the end of the 2nd night they showed me their API definition and design, as well as the web interface meant for humans. I felt they struck a perfect balance between the tech and human aspects of delivering human services. This balance is a topic you will here more about here on the blog as I talk about APIs, and how they are being wielded for artificial intelligence, machine learning, voice, bots, and every other digital layer of our world that often seems to be being consumed by technology. I’m always looking for the emphasis of human over the technology, and I am pleased with the outcome of this hackathon. I’ll showcase the work once we are done. It is something I’m thinking will be useful in supporting future natural disasters, something I’m feeling is going to become a more common occurrence in our world.