A Hollywood staple of the 1930s and 1940s was the story of a plucky band of young kids—usually led by Mickey Rooney and Judy Garland—who, their dreams of making it on Broadway dashed by some plot twist, decide to stage a show of their own. They would find a barn or a warehouse, sing and dance and tell a few jokes on a makeshift stage, and then some theatrical bigshot standing in the wings would snap his fingers—and in the final scene, we’d see Mickey and Judy opening on the Great White Way.
If they remade one of those movies today, the plot would be nearly the same, but would undoubtedly revolve around software.
Case in point: Last month, New York University’s Rudin Center and the Transit Center hosted a one-day hackathon to come up with ideas for improving bus service on Staten Island. Like many places, transit routes on the island are mostly a slightly evolved hodge-podge based on historical streetcar lines, with service levels and timetables that have changed incrementally over the years. New York City’s fifth borough is its most suburban, and its residents have long average commutes, and a wide range of destinations, including Manhattan, Brooklyn and New Jersey.
The Hackathon was held March 5 and drew a solid cadre of laptop-wielding, data-infused programmers, who labored all day to produce a software and presentations to show how the buses could indeed be better. The competition’s $2,000 Grand Prize went to Sri Kanajan for a map the visualized the concentration of bus trip origins and destinations.
Credit: Sri Kanajan
While colorful and interesting, the map is chiefly a restatement of the problem, rather than a proposed solution. It’s useful to have a data-driven, visual representation of the Staten Island origins (dispersed) and Manhattan destinations (concentrated, mostly in the financial district and Midtown), of current bus riders. And, from all accounts, the hackathon generated a healthy discussion of the key problems that need to be addressed in improving transit service.
In our view, anything that gets people talking about buses is generally a good thing. Buses are the underappreciated work-horses of the public transit system, and anything we do that gets them running more efficiently can produce widespread benefits. Case in point: Houston’s rearrangement of its bus routes to implement a gridded, timed-transfer system, providing more frequent service to the most heavily patronized destinations.
And we’re the last ones to argue that only expensive experts can have good ideas. It’s often very productive to have bright outsiders with a fresh perspective re-frame questions and brainstorm new ideas. But at some point—and optimizing transit routes is one of them—a level of expertise and practical experience that even the best programmer isn’t going to deduce from even the biggest data—at least not in the first attempt.
But maybe the bigger problem is that there’s a certain tyranny in the limitations of existing data: current transit ridership data reflects, in part, the pattern and quality of the current service system. There’s some necessary risk-taking and abstraction to apply the lessons from experience in say, other cities, in order to be able to imagine the potential opportunities of a service model for which there is no current local exemplar. In addition, the organizers of the hackathon decreed that all proposals for rearranging transit service had to be “cost-neutral”—a condition that begs the question of what level of resources ought to be devoted to bus service (an especially ironic issue, given the billion-dollar-plus price tag of other New York City transit investments like the $1.4 billion Fulton Center and $4 billion Calatrava WTC station).
The blinders clamped on by the limits of existing data or institutionally siloed problem definitions isn’t just the province of plucky volunteers. Last month we pointed out that design firm IDEO’s efforts to reimagine transportation on behalf of one of its corporate clients was plagued with a fundamental failure to correctly (and broadly define the problem) which led them to overlook thinking about the important roles that urban form and location choices could play in addressing transportation needs.
A couple of years back, a Brooklyn based startup, then called “Significance Labs,” proudly unveiled its smartphone app to enable the poor to prepare applications for food stamps, trumpeting it as a way for the poor to more readily access nutrition benefits. Its founder, a former Facebook and Linkedin veteran, said he wanted to extend SNAP to the “80 percent of the poor” who own smartphones. It would help them cope with the ordeal of applying for SNAP benefits. Next City related their business plan:
“We’ve all been annoyed at some point by navigating government services like waiting in line at the DMV, or filing taxes or applying for a passport,” says Chen. “For low-income Americans, it’s no longer just an annoyance, it’s a necessity. The system, despite being more important for these Americans, isn’t any easier for them.”
Never mind that according to Pew, aggregate smartphone for the entire population was 68 percent in 2015 (and considerably lower for the poor). People who are poor, and who have difficulty getting SNAP benefits are pretty much the least likely among us to own and use smartphones. There’s precious little evidence that the application process is a very big barrier to accessing SNAP benefits: eligible non-recipients are disproportionately elderly and disabled or lack language skills—barriers that seldom correlate strongly with smartphone ownership, much less use.
What’s especially egregious is the implication that it is the “app” that’s solving the hunger or poverty problem. The secret sauce here is not the app, but the dollar value of SNAP benefits. And the problem with SNAP benefits is not that there isn’t an app, but that Congress has been steadily whittling away at the population eligible for benefits and reducing the value of the benefits themselves. Defining this as primarily a technology problem distracts attention from this central issue.
More generally, it’s far from clear that privately developed apps are necessarily a good way to provide access to public services. (While there are plenty of useful, free apps—Google maps has seamlessly integrated transit directions in most cities, thanks to the widespread adoption of open data standards for transit schedules). One article praising Easy Food Stamps called it a “Turbo Tax” for the SNAP program. Turbo Tax has certainly simplified the process of filing one’s taxes, for a price. But the company has also fiercely defended its turf: lobbying Congress to prevent the IRS from offering automatic simple and free tax preparation services, something that could replace the 1040EZ form.
At some point, this kind of techno-centrism is more than just tone-deaf. Blogger Alex Payne diagnosed this particular behavior in claims that BitCoin—the cybercurrency—would help the un-banked poor:
Silicon Valley has a seemingly endless capacity to mistake social and political problems for technological ones, and Bitcoin is just the latest example of this selective blindness. The underbanked will not be lifted out of poverty by conducting their meager daily business in a cryptocurrency rather than a fiat currency.
Open data, apps and technology are all important tools for addressing a range of problems. We really ought to use technology to broaden the audience and inject fresh perspectives into a wide range of discussions. But we shouldn’t let our fascination with technology lead us to believe that there are cheap and easy solutions to complex problems. Technology is usually a complement to, and not a substitute for resources, programs and investments. Open tech needs to be viewed as a way of expanding the discussion, bringing in new perspectives and widening the range of considered alternatives, rather than being treated as a panacea.
So let’s definitely hack away. But if you’re looking to figure out a real challenge for programmers, here’s a thought: instead of spending a billion dollars widening I-75 in Detroit, let’s have a freeway hackathon.
The limits of technology: Let’s hack an app
A Hollywood staple of the 1930s and 1940s was the story of a plucky band of young kids—usually led by Mickey Rooney and Judy Garland—who, their dreams of making it on Broadway dashed by some plot twist, decide to stage a show of their own. They would find a barn or a warehouse, sing and dance and tell a few jokes on a makeshift stage, and then some theatrical bigshot standing in the wings would snap his fingers—and in the final scene, we’d see Mickey and Judy opening on the Great White Way.
If they remade one of those movies today, the plot would be nearly the same, but would undoubtedly revolve around software.
Case in point: Last month, New York University’s Rudin Center and the Transit Center hosted a one-day hackathon to come up with ideas for improving bus service on Staten Island. Like many places, transit routes on the island are mostly a slightly evolved hodge-podge based on historical streetcar lines, with service levels and timetables that have changed incrementally over the years. New York City’s fifth borough is its most suburban, and its residents have long average commutes, and a wide range of destinations, including Manhattan, Brooklyn and New Jersey.
The Hackathon was held March 5 and drew a solid cadre of laptop-wielding, data-infused programmers, who labored all day to produce a software and presentations to show how the buses could indeed be better. The competition’s $2,000 Grand Prize went to Sri Kanajan for a map the visualized the concentration of bus trip origins and destinations.
While colorful and interesting, the map is chiefly a restatement of the problem, rather than a proposed solution. It’s useful to have a data-driven, visual representation of the Staten Island origins (dispersed) and Manhattan destinations (concentrated, mostly in the financial district and Midtown), of current bus riders. And, from all accounts, the hackathon generated a healthy discussion of the key problems that need to be addressed in improving transit service.
In our view, anything that gets people talking about buses is generally a good thing. Buses are the underappreciated work-horses of the public transit system, and anything we do that gets them running more efficiently can produce widespread benefits. Case in point: Houston’s rearrangement of its bus routes to implement a gridded, timed-transfer system, providing more frequent service to the most heavily patronized destinations.
And we’re the last ones to argue that only expensive experts can have good ideas. It’s often very productive to have bright outsiders with a fresh perspective re-frame questions and brainstorm new ideas. But at some point—and optimizing transit routes is one of them—a level of expertise and practical experience that even the best programmer isn’t going to deduce from even the biggest data—at least not in the first attempt.
But maybe the bigger problem is that there’s a certain tyranny in the limitations of existing data: current transit ridership data reflects, in part, the pattern and quality of the current service system. There’s some necessary risk-taking and abstraction to apply the lessons from experience in say, other cities, in order to be able to imagine the potential opportunities of a service model for which there is no current local exemplar. In addition, the organizers of the hackathon decreed that all proposals for rearranging transit service had to be “cost-neutral”—a condition that begs the question of what level of resources ought to be devoted to bus service (an especially ironic issue, given the billion-dollar-plus price tag of other New York City transit investments like the $1.4 billion Fulton Center and $4 billion Calatrava WTC station).
The blinders clamped on by the limits of existing data or institutionally siloed problem definitions isn’t just the province of plucky volunteers. Last month we pointed out that design firm IDEO’s efforts to reimagine transportation on behalf of one of its corporate clients was plagued with a fundamental failure to correctly (and broadly define the problem) which led them to overlook thinking about the important roles that urban form and location choices could play in addressing transportation needs.
A couple of years back, a Brooklyn based startup, then called “Significance Labs,” proudly unveiled its smartphone app to enable the poor to prepare applications for food stamps, trumpeting it as a way for the poor to more readily access nutrition benefits. Its founder, a former Facebook and Linkedin veteran, said he wanted to extend SNAP to the “80 percent of the poor” who own smartphones. It would help them cope with the ordeal of applying for SNAP benefits. Next City related their business plan:
“We’ve all been annoyed at some point by navigating government services like waiting in line at the DMV, or filing taxes or applying for a passport,” says Chen. “For low-income Americans, it’s no longer just an annoyance, it’s a necessity. The system, despite being more important for these Americans, isn’t any easier for them.”
Never mind that according to Pew, aggregate smartphone for the entire population was 68 percent in 2015 (and considerably lower for the poor). People who are poor, and who have difficulty getting SNAP benefits are pretty much the least likely among us to own and use smartphones. There’s precious little evidence that the application process is a very big barrier to accessing SNAP benefits: eligible non-recipients are disproportionately elderly and disabled or lack language skills—barriers that seldom correlate strongly with smartphone ownership, much less use.
What’s especially egregious is the implication that it is the “app” that’s solving the hunger or poverty problem. The secret sauce here is not the app, but the dollar value of SNAP benefits. And the problem with SNAP benefits is not that there isn’t an app, but that Congress has been steadily whittling away at the population eligible for benefits and reducing the value of the benefits themselves. Defining this as primarily a technology problem distracts attention from this central issue.
More generally, it’s far from clear that privately developed apps are necessarily a good way to provide access to public services. (While there are plenty of useful, free apps—Google maps has seamlessly integrated transit directions in most cities, thanks to the widespread adoption of open data standards for transit schedules). One article praising Easy Food Stamps called it a “Turbo Tax” for the SNAP program. Turbo Tax has certainly simplified the process of filing one’s taxes, for a price. But the company has also fiercely defended its turf: lobbying Congress to prevent the IRS from offering automatic simple and free tax preparation services, something that could replace the 1040EZ form.
At some point, this kind of techno-centrism is more than just tone-deaf. Blogger Alex Payne diagnosed this particular behavior in claims that BitCoin—the cybercurrency—would help the un-banked poor:
Silicon Valley has a seemingly endless capacity to mistake social and political problems for technological ones, and Bitcoin is just the latest example of this selective blindness. The underbanked will not be lifted out of poverty by conducting their meager daily business in a cryptocurrency rather than a fiat currency.
Open data, apps and technology are all important tools for addressing a range of problems. We really ought to use technology to broaden the audience and inject fresh perspectives into a wide range of discussions. But we shouldn’t let our fascination with technology lead us to believe that there are cheap and easy solutions to complex problems. Technology is usually a complement to, and not a substitute for resources, programs and investments. Open tech needs to be viewed as a way of expanding the discussion, bringing in new perspectives and widening the range of considered alternatives, rather than being treated as a panacea.
So let’s definitely hack away. But if you’re looking to figure out a real challenge for programmers, here’s a thought: instead of spending a billion dollars widening I-75 in Detroit, let’s have a freeway hackathon.
Related Commentary