Traction motor, HVAC unit, AVL system?

If a transit agency runs its own motor shop for rebuilding traction motors, runs its own electronics shop for performing component-level repair of circuit boards, runs its own axle shop for rebuilding axles, why shouldn’t it be able to do the same for the software which is just as vital to everyday operation as axles and traction motors?

I recently came across a very interesting paper describing the successes of SEPTA’s Woodland Electronic Repair Shop. At SEPTA, the justification for in-house electronics repair is twofold: many components which come into the shop are not actually defective, and had they been sent to an outside shop for repair, time and money would have been wasted only for the outside shop to return the same “no trouble found” verdict, and, secondly, sending equipment to an outside shop is expensive—by SEPTA’s analysis, more than double the cost of operating an in-house electronics shop.

Transit agencies may not think of themselves as being technology-oriented, but the reality is that software systems are at the heart of so many things transit agencies do—from scheduling to passenger information to signals and communications. Agencies almost universally rely on vendor support for large software packages that perform a wide range of functions: scheduling, trip planning, real-time passenger information, and even safety-critical tasks in signalling and communications.

Yet in comparison to the nuts and bolts which keep the a transit system moving, most transit agencies have shockingly little control over their vital software. Being closed-source and proprietary, the agency is unable to develop its own bug fixes, patches, and new features, and may not even be able to export data in an open format. By controlling the availability of support and new features, the vendor dictates when the agency upgrades—and by using proprietary data formats and interfaces, the vendor all but guarantees that the agency will return to them instead of shopping around. This is the very same risk that SEPTA’s electronics shop seeks to mitigate:

At some point the vendor will no longer support their particular system and since you have always relied upon them for their parts you will have no choice but to go out for bid to get a new system or an alternately designed part to perform the same function.

When procuring new equipment, SEPTA demands access to schematics and test equipment, so that their repair shop can do its work. Without this access, the results are predictably poor. SEPTA found that costs for one class of parts had increased 94% over two years—an “astronomical” price increase at an agency used to inexpensive in-house repair. The explanation, from SEPTA’s engineering department, is depressing:

These are so expensive because SEPTA has no alternative but to purchase these parts from the OEM.

This is why our equipment specifications have a requirement that the Vendor provide SEPTA with all test equipment, documentation and training to allow us to repair the circuit boards in our electronic repair shop at Woodland. The CBTC project did not have a specification from Engineering, but rather was supplied for liquidated damages from the M4 program. It was understood from the beginning that SEPTA would not have the capability to repair the circuit boards.

The complexity and safety aspect of these boards prevents SEPTA from creating drawings and specifications that would allow an alternate supplier to produce these boards.

So, what is the parallel for a software project? Where an electronics shop has schematics, where a mechanical shop has blueprints, a software shop has source code and supporting tools. When a transit agency has access to the source code for a software system, they can perform their own in-house work on the system, on their own schedule, and with their own staff. New features are developed to meet the agency’s needs, not according to a vendor’s whims. Even if the agency elects to bring in contracted support to develop bug fixes or new features, they retain complete control over the process—and, more importantly, they own the end product.

Transit agencies may feel ill-at-ease at the prospect of getting into the business of software development, but the reality is that by bringing software skills in-house, they can realize the same gains as when they bring mechanical and electronic repair and overhaul in-house. In fact, the potential gains are even greater for software, when agencies use open-source software and actively participate in the surrounding community. Many of the fundamental problems of mass transit are the same from agency to agency, and software developed to solve a problem at one agency is very likely to be usable (at least in part) at other agencies.

For San Francisco, and governments everywhere, technology startups are the perfect partners

A recent article in the New York Times describes SMART Muni, “an Apple iPad app that uses Global Positioning System technology to track all of the city’s buses in real time, allowing transit managers and passengers to monitor problems and delays”. It sounds like the perfect success story: civic coders taking open data (Muni tracks its buses and trains with NextBus, which provides an XML data feed) and using that data to improve operations and create real value for the agency.

Unfortunately, it’s not a success story: the app has never been used in production. As the article explains, “Muni hopes to put the app to good use some day, but the agency is $29 million over budget and cannot afford to buy the iPads required to run the software…[nor] is the city willing to invest $100,000 to run a pilot program.”

The costs involved here—a few hundred dollars each for some iPads, perhaps a few thousand dollars to fund a stipend for a civic coder, even $100,000 for a pilot—pale in comparison to the costs associated with the big-name IT consulting firms that governments are used to dealing with.

In addition, startups, teams of civic coders, and open source projects can often deliver a working prototype or even a completed project much faster than conventional development teams. As the New York Times describes, “a small team of volunteers took just 10 days last summer to create [the app].”

Unfortunately, the City of San Francisco is out of touch with the realities of technology: “‘Start-ups fail at a high rate,’ said Jay Nath, chief innovation officer of San Francisco. ‘As stewards of taxpayer dollars, we need to be thoughtful of using that money wisely and not absorbing too much risk.'” Nath is right about one thing: start-ups do fail at an alarming rate. But that’s not the risk you might think it is, because startups aren’t like conventional development projects.

Unlike conventional projects, startups fail fast. Instead of wasting years and millions of dollars, when a startup has an idea that isn’t going anywhere, it winds up quickly. Maybe it was a bad (or even outright infeasible) idea to begin with, or the startup had the wrong team, or they tried to do too much at once. Maybe their idea’s been superseded by a newer, even better technology. Whatever the reason may be, the startup doesn’t just grind away for years, running up a million-dollar bill. Instead, they admit that they can’t deliver, and get out gracefully.

Consider, for example, the FBI’s Virtual Case File, a five-year, $170-million development effort that never actually delivered any working software. Imagine if the VCF project had failed after three or six months, not five years. Imagine if it had spent less than a million dollars before failing, not $170 million. Of course, the project still wouldn’t be done—but we’d have known that something was wrong up front, instead of finding out five years later, after millions of taxpayer dollars had been wasted on a doomed development effort.

More importantly, startups do have the agility necessary to keep up with the ever-changing technology marketplace. A development effort that takes five or ten years is bound to deliver a product that is obsolete as soon as it arrives, unless major changes are made along the way.

The conventional development practices used by many government agencies and their contractors don’t incorporate that kind of agility. Specifications and requirements are written early in the project’s life, perhaps even before a development team has been selected (if the project must be put out for bids). Even if the requirements are found to be lacking—or flat-out wrong—development marches on. In the end, the team will deliver a product that meets the requirements (thus satisfying the bean-counters) but which is already out-of-date and which doesn’t actually do what users need it to do.

I alluded to these problems in my recent coverage of WMATA’s initiative to install real-time information displays at bus stops. By only considering bids from vendors with “standard, proven products” and “successful existing and fully operational implementations, in multiple transit agencies”, they potentially shut out innovative startups (or even teams of civic coders, like the Mobility Lab).

It’s entirely possible that the first team to tackle a thorny problem may fail—but rather than casting them as “failures that burn holes in the city’s budget”, we’ve got to communicate to governments and taxpayers alike that not all failures are the same. There’s a big difference between a project that runs for years, spends millions of dollars, and has nothing to show for it in the end, and a project that fails after just a few months, has spent well less than a million dollars, and can identify what went wrong, so the next project will be more successful.

When it comes to technology, the best way for governments to be good ‘stewards of taxpayer dollars’ is to adopt successful development practices: small, agile, competent teams, that build inexpensive, flexible products, and fail quickly if they can’t get the job done. The old way—forking over millions and millions to high-priced contractors until they finally declare defeat, then taking it up in a years-long legal battle—just doesn’t look like good stewardship anymore. Sure, established companies may have a long track record that startups don’t, but what’s it a record of? We don’t need any more million-dollar failures. We need smart civic coders developing next-generation solutions like SMART Muni, and we need governments to accept, embrace, and support them.

WMATA to bidders: don’t innovate with real-time signs

Last week, I asked if WMATA would entertain the idea of using a modern, open-architecture, open source system to power real-time signs at Metrobus stops. Unfortunately, I can now conclusively say that that will not be the case. When I first read the RFP, WMATA had yet to post the complete technical specifications. They’ve now updated the RFP with the complete technical specifications (albeit in an inaccessible, untagged PDF which is itself a scan of a printout).

The specifications state, in part:

Because of the criticality of meeting the firm deadlines, WMATA wants only to procure standard, proven products, from a Vendor with successful existing and fully operational implementations, in multiple transit agencies.

WMATA specifically does not want to assist a Vendor in developing new products for its product line for this RFP.

Furthermore, WMATA wants to select a Vendor that has clearly made a long-term commitment to providing contemporary customer information systems to the transit industry.

So, that’s that. I could go on at great length about how MTA New York City Transit’s success with OneBusAway, and how we could do the same for real-time signs, but I’ve already made that argument.

I’ve long known that WMATA is an agency which is deeply suspicious of change and innovation, and it pains me to see the agency continue to behave in ways that are manifestly counterproductive and which will in all likelihood only deepen the agency’s budget deficit.

Continue reading WMATA to bidders: don’t innovate with real-time signs

On WMATA’s RFP for real-time signs

WMATA recently released an RFP for real-time signs for bus passenger information. Since I don’t want to completely bore people with a series of thousand-word posts as I did for WMATA’s New Electronic Payments Program, I decided to package up my earlier tweets about the RFP, along with a few notes, into a post on Storify.

I’ve also embedded the post below:

Continue reading On WMATA’s RFP for real-time signs

Kermit: more than a file transfer program, a tangible link to the past

Thirty years ago today, the first file transfer was made using the Kermit protocol, the brainchild of the Kermit Project. Originally designed to link workstations to mainframes, the Kermit Project grew to encompass software for dozens of platforms. The main versions of Kermit today, C-Kermit and Kermit 95, do more than just transfer files; they also function as terminal emulators with advanced scripting capabilities. But the Kermit Project will not see the end of its thirty-first year, for it has been terminated by Columbia University, effective July 1, 2011.

Some may consider this to be a small loss—after all, the Kermit software may seem like a relic of days past, when TCP/IP was not the common denominator it is today, and SSH did not yet even exist. But I think the real value in Kermit is not just the software itself, but in what it stands for. In an industry that seems to forget its history and tries to reinvent everything every few years, the Kermit Project has managed to keep the software up-to-date and relevant without losing touch with its roots. Kermit today will happily communicate with older systems, a fact taken advantage of by retrocomputing enthusiasts and technologists needing a way to migrate data off of dinosaurs. You may have a hard time making the physical connection—after all, serial ports have become awfully hard to find lately—but if you can, you’ll find that Kermit will happily communicate with a decades-old computer just as well as one from today.

At the same time, modern Kermit clients are also perfectly capable of working in today’s networked environment; Kermit clients today support network links over Telnet, FTP, HTTP, and SSH. And all of these features can be scripted using Kermit’s built-in scripting language. The scripting language takes some getting used to, but once you get the hang of it, it’s really quite useful.
Continue reading Kermit: more than a file transfer program, a tangible link to the past