A Streetcar Named Misfire

The DC Streetcar project has been an ongoing boondoggle for a long time, but it may finally be coming to something close to an end. The system will open for business on February 27, or at least something close to “for business.” In what appears to be a rush to get the streetcar running before some arbitrary date, a few unfortunate choices have been made.

  • The car barn at Spingarn High School isn’t ready. I suppose DDOT has had some way of maintaining the cars during the test runs that have been going on for the last year or two, but that was under non-revenue service. With all of the cars running and carrying passengers, maintenance becomes more critical to safety and performance. I hope they’ve figured out what to do in the interim.
  • There will be no Sunday service at launch; it “may be phased in at a later date.” This reeks of cost-cutting, and is unfriendly to customers, as well as the businesses along H Street that have moved in anticipating the streetcar – now they’ll only get its benefits six days out of the week. (Update: Sunday service started on September 18. Great job!)
  • The biggest problem is that the streetcar, when it does start charging fares (it’s free for a limited time) will not accept SmarTrip. The justification is that Metro is planning to move on from SmarTrip… some day. The contactless payment pilot last year reportedly did not go well, and given Metro’s current sorry state of business and operational affairs, I wouldn’t expect them to move forward with this plan any time soon. Yet DDOT has decided to trust Metro to get things done, and rejected the single form of fare payment that is otherwise almost universally accepted across this region. It’s unfortunate, and could be a shot-in-the-foot decision.

As I said in the opening, this looks like a decision to just launch some kind of service with what’s ready now in order to meet some self-decided deadline or keep some promise to someone, not a ready-for-prime-time opening. How hard would it have been to keep at least some Sunday service? Or to get a few of the handheld SmarTrip readers that MTA light rail ticket inspectors carry?

I suppose after the perpetual “Charlie Brown and the football” situation that has dogged the streetcar for years, this is still some kind of progress, but it still feels like Lucy yanked the ball away again. This is no way to run a customer-friendly, sustainable business.

Thoughts On Transit In Apple Maps

(This article has been updated several times since I first wrote it. See the list of updates at the end.)

As you might recall from some of my earlier writing, I ride transit a lot. Now that I’m no longer working from home every day, I’m back to riding transit to work four or five days a week. I also have Apple devices, including MacBooks and iOS gadgets. And, like many people, I’m increasingly weirded out by Google (or Alphabet or some Venn diagram thereof) tracking everything everywhere, so I’m trying to avoid Google Maps.

So it’s nice that, for the first time since Apple punted Google Maps from iOS and built their own Maps app, that app will include transit directions, starting in a handful of major cities with the imminent OS X El Capitan and iOS 9 releases. The Washington, DC area, where I live, is one of the launch cities for transit in Apple Maps, as are many places I visit often, have visited recently, or will visit soon: Baltimore, Philadelphia, New York, Chicago, Toronto, and San Francisco. (I’m hoping other places I seem to end up at least once a year, like Boston and Portland, will be added in future releases.)

I’ve been running the El Capitan and iOS 9 public betas for a few months, so I’ve seen a bit of how this was going to work, but New York was the only city that was live during the beta phase. The rest of the launch cities are now live, so I’ve had an opportunity to see how this is really going to work when it goes live for everyone who doesn’t live in New York.

The Interface: Google Maps and similar apps have defined the expected UI for transit routing already, and Apple Maps doesn’t deviate much from it. You enter your start and finish points, choose from a few route options, and get on your way. Where available, tapping a stop/station in the map will bring up a list of which routes stop there and estimated arrival times. One thing missing compared to some competitors is the option to specify more/less walking, fewer transfers, or to prefer buses/trains/light rail/etc. That’s not an option I used often in other apps, but some people might miss it.

Transit System Coverage: Coverage for different transit options in the launch cities is pretty comprehensive. In DC, you have Metrorail, Metrobus, Circulator, Ride On, ART, Fairfax Connector, DASH, PRTC, MTA commuter buses, RTA (former Howard Transit/Connect-A-Ride), MARC, VRE, and the DC Streetcar. In Baltimore, you’ve got the Metro Subway, Light Rail, MTA local buses, and Charm City Circulator. Of the list of agencies accepting smartcards in DC and Baltimore, that’s only missing Loudoun Transit, CUE, and TheBus.

Looking at other cities, Philadelphia has all of SEPTA’s services, plus PATCO. New York has all of MTA’s buses and subways, LIRR, Metro-North, PATH, the Staten Island Ferry and SI Railway, and NY Waterway. In between, all of NJ Transit’s local buses, light rail, and commuter rail look to be available. Chicago has the L, CTA and Pace buses, and Metra. The Bay Area has BART, Muni metro, all of the local bus systems, VTA light rail, Golden Gate and San Francisco Bay ferries, Caltrain, and (yes, even) the cable cars. In Toronto, all of the TTC buses, subways, and streetcars are there, as are GO Transit trains and buses; I’m told many of the regional operators in the Toronto area are there too, but I didn’t look. Airport trains at JFK, EWR, and SFO are also included.

If one of the reasons Apple took this long to add transit info to Maps is because they wanted to be sure it was a comprehensive offering, they’ve succeeded. They’ve included nearly everything a transit rider would ride in the launch cities.

Nomenclature: With one exception (which I’ll get to shortly), Apple has also identified each station with the logo of the agency offering it, and the same names and colors the agencies use. For instance, BART stations are shown with the “ba” logo, and the lines are colored the same as on the official BART map, but because no one in the City calls BART lines by those colors, Apple Maps doesn’t either. SEPTA uses different logos for the Market-Frankford Line and the Broad Street Line, and so does Apple Maps. Even the bus stop symbols are colored much like the agencies that run them (gray with red stripes for Metrobus, gold for MTA buses based on the flag logo, etc.)

The one exception is that Metrorail lines are identified properly by color, but not by the abbreviations that Metro uses. Apple Maps uses single letters: R for red, O for orange, etc. Metro uses double letters: RD for red, OR for orange, etc. This has the potential to be confusing for visitors who want to know when the next “B train” is. However, I don’t think this is a huge deal because Apple did get the colors right, and everyone calls the lines by colors instead of the double-letter abbreviations.

Map Display: Before starting a trip, you can view a map with rail lines highlighted (but not buses, because that would be way too busy to be useful.) When in transit mode, streets and roads that are not likely to be relevant (such as freeways) are dimmed, as are highway route numbers. Street names are still shown, since you’ll likely need to know which street you walk down after you get off transit. Overall, it’s a pretty useful view.

One thing Apple highlighted in their demonstrations is that they show the layout of train stations, including where the entrances and exits are. This is really useful for large, complex underground stations like Times Square or the City Hall/15th Street/Suburban Station concourse in Philly. It may be less useful for things like street-level light rail platforms, but at least Apple is consistent about it.

Other Little Things: A few other minor observations:

  • The 34th St-Hudson Yards 7 train station in New York is shown, even though it doesn’t officially open until tomorrow. If you try to route to it today, Maps will correctly tell you the 7 train ends at Times Square. Future-proofing is good, but present-proofing is even better.
  • The SEPTA regional rail station immediately east of Suburban is called Jefferson in Apple Maps, even if most locals still call it Market East. Not a complaint – Apple should be using the official names for things – but an indication of Apple’s data being up-to-date, as this is a fairly recent change.
  • When routing and finding the nearest stop/station to start from, Apple Maps seems to go at least partially on what station you can walk to over paths shown on the map, not strictly on straight-line distance from your current location. This is important; the nearest Metrobus stop that I can legally walk to from my home is not the same as the nearest Metrobus stop as the crow flies. Other routing apps tend to get this wrong.

What I’d Change: All in all, this is a solid first offering by Apple, which they can iterate on to make the service even better. Here’s what I’d do:

  • Add more cities, obviously. Of places I’ve visited with complex transit systems, I’d add Boston, Los Angeles, Montréal, Seattle, and Portland (maybe in that order, maybe not.) And, of course, more coverage outside North America, but Apple tends to start closer to home.
  • Be a little more clear when multiple services converge on one
    spot.
    Newark Penn Station, for instance, is a terminal for the Newark City Subway and PATH, and a major station for NJ Transit rail. In my testing, I sometimes had trouble seeing the icons for all three services.
  • Add fare information, especially for the systems like Metrorail and BART that don’t run on a flat fare system. For fare systems that theoretically support Apple Pay (Ventra and, soon, SEPTA Key) they could indicate that as well.
  • Consider adding Amtrak. Whether or not Amtrak qualifies as mass
    transit is a debate that could be interesting, but I’m not going to engage in it here. Apple Maps does have the Amtrak Capital Corridor in San Jose and the East Bay, which is essentially a commuter rail line anyway, but I’d also add Acela and other Northeast Corridor services, and the various Illinois services centered on Chicago. (And, if LA/San Diego and Seattle/Portland ever make it into Apple Maps, I’d add the Pacific Surfliners and Cascades too.)
  • Fix the Metrorail single-letters thing. It’s a minor detail, but Apple is known for attention to minor details, and so many minor details about Apple Maps transit are so well done. This should be a relatively simple fix.

Updates

  • Apple has added many new cities since this article was written, including all of the cities I suggested.
  • The Metrorail single-letters thing has been fixed, as has the spacing of multiple service icons at a single location. I really like how Apple is not just letting this feature sit “completed”, but is iterating and improving it as time goes on.
  • The DC Streetcar (about which I’ve written a bit) started revenue service on February 27th. Apple Maps included the Streetcar’s service on day one. Nicely done.
  • CUE and TheBus stops now appear on Apple Maps as of June 19, 2016. As of July 17, TheBus schedule information is in the app as well!

Gratitude

By now, just about everyone’s heard of the DevOps virtues of Culture, Automation, Measurement, and Sharing, or CAMS. (Some also add Lean in there to make CALMS, or CLAMS if you’re into seafood.) While it doesn’t make for a snappy acronym, I think we should add one more virtue: Gratitude.

Whatever you do with your life, there’s something in your life to be thankful for. For those of us who’ve been working in the DevOps fields for a long time, there’s a lot to be thankful for right now. We have skills that are in demand. Cloud computing has, for many of us, made our tasks much simpler and eliminated those dreaded treks to the data center. Automation and the infrastructure-as-code concept have brought discipline, agility and flexibility to our stacks. The DevOps movement has broken down the walls that kept people separated from each other instead of working together towards common goals. These are all things that have made my life better as a long-time system administrator and developer, and I’m grateful for them all. My late father was a sysadmin in the days of big iron and dedicated systems, and in his retirement was always impressed with what we can do today compared to the rigors and limitations of the old school. When you can do something better than your dad, that’s definitely something to be thankful for.

But beyond gratitude for the current state of our industry, and the bright future ahead, we should be grateful for the real heart of the industry: the people. If I have taken nothing else away from the DevOps community, it is that the community itself is the greatest thing about DevOps. Not the philosophy; not the culture in action; not the tools that tool-vendors are lazily labeling as “DevOps” tools; but the people who are out there doing great things, and talking about them, and sharing their playbooks, and helping others do great things as well. You see it in events like DevOpsDays and Monitorama, in publications like The Phoenix Project and the DevOps Weekly, and in the meetups and other gatherings of like-minded people looking to connect.

And while the people putting on conferences need to pay the bills, and the authors of books would love if you bought a copy, for the most part, they’re not in it for the money. They’re in it as a way of saying “thank you” to the community that helped them get where they are, and to likewise help you get where you’re going as well. Is it paying back, or paying forward? Both, if you ask me. Gratitude goes both ways – as an acknowledgement of what’s come before, and an encouragement of what’s to come.

If you’re doing great things with DevOps, take some time to express your gratitude to those who’ve helped you get there. And as you do great things, share them with the world and feel the gratitude of others. If you ask me, there’s no better feeling in the world than knowing that something you did made someone’s life better, and that’s what gratitude is all about. And, in the end, isn’t that what DevOps is all about, too?

Work-Life Balance Necessarily Includes Life

I’ve just returned from a week in Colorado, meeting with my colleagues at TeamSnap. We do these company-wide meetings about twice a year, bringing in most (if not all) of the team from around the world to discuss business, collaborate on new ideas, and have fun doing so. (If this sounds a lot like what some other businesses call an “offsite”, you’re right. That word sounds a little odd to me given that around 34 of TeamSnap works remote, but maybe I’m overthinking things.) At this meeting, many people commented on the quality and humor of my writing for internal consumption. So I’m starting this new blog to share some of that style with the rest of the world. And I’ll start with a story about how we do things at TeamSnap.

The thing I like the most about working at TeamSnap is that when we say there is a “work-life balance”, we mean it. We understand that in order for people to do their best work, they need to have time to pursue their best life, too. We don’t do “overtime” here. You work until your job is done for the day, and then you sign off and go have some fun. If that means you only put in five hours one day, so be it. If that means you pull a few extra hours to get something done right, that’s great. What it doesn’t mean is that we want people stuck at their desks for eight hours a day and five days a week. You are, within reason, empowered to work when, where, and how you want at TeamSnap, as long as you are doing your job and delivering the expected results.

Andrew Berkowitz, who co-founded TeamSnap and is now our Chief Product Officer and Minister Of Culture, recently discussed this philosophy in terms of our vacation policy, or lack thereof. We do not have a fixed number of days off, and TeamSnap employees are encouraged to take time off when and where they want or need to. There are probably law-and-order-type HR managers who bristle at this idea, saying some people would take advantage of this policy to slack off, never show up for work, and not deliver. These managers are right, but our response is simple: we do our best not to hire this sort of person. To paraphrase Stan Lee, with great freedom comes great responsibility; we look for people who are good at managing their own time, who don’t need managers checking in with them daily to stay on task, and who can deliver what’s needed when it’s needed. The type of person who doesn’t show up and doesn’t deliver doesn’t fit in at TeamSnap any more than she or he would fit in elsewhere.

What this comes down to, in the end, is treating people like people, and specifically treating adults like adults. Too often in the world, we say that people come into our organizations as untrusted plebes, and must earn the trust and respect of the elders, or some such thing. At TeamSnap, if we’ve offered you a job, we implicitly trust you to do it and do it right. There is no inner sanctum, but if there was, you’d be welcomed into it on day one. This is how we’re able to do things like allow most of the company to work remotely, take as much time for life away from work as they need, and speak up whenever you feel the need, to whoever seems appropriate.

I’m not posting this to recruit for TeamSnap, but to challenge those of you in a position to influence your company’s culture. Why do you have the policies you do around things like paid time off? Do you believe that setting limits on responsible adults prevents the irresponsible ones from screwing up? Does one bad apple really spoil the whole bunch? What would really be the impact to your business if you let any of your “crucial” people take off whenever they like? Is one person that “crucial”, really? Isn’t that a lot of pressure?

Better Ticketing for MARC

Getting tickets for MARC is a fairly confusing process. There are various ways to get a ticket, all of which have their own idiosyncracies about them:

  • At stations that have them, you can buy tickets from Amtrak ticket machines. This includes not only the stations that are also Amtrak stations (Union Station, New Carrollton, Penn Station, Rockville, etc.) but also some other stations that are not served by Amtrak (Camden Yards, Savage, etc.) These machines only accept credit/debit cards, not cash. Many stations do not have these machines.

  • If you’re boarding at a station that doesn’t have an Amtrak machine, you can buy a ticket on board. Conductors on board only accept cash, not credit/debit cards. Additionally, there is an extra charge for paying cash on board if you boarded at a station with an Amtrak machine.

  • You can buy tickets in person at local commuter stores, almost all of which are located in Virginia, where MARC offers no service. (2015 update: there will be a commuter store at the new Sarbanes Transit Center in Silver Spring, which opens next week. Huzzah!)

  • You can buy tickets in person at most Amtrak stations where MARC stops, if you can get there by some other means.

  • You can buy tickets in person at the MTA office in Baltimore, if you can get there (it’s in the Willy-Don Schaefer building.)

  • You can buy tickets by mail, if you are buying a weekly/monthly pass.

I live in Greenbelt, which has a MARC station with no machines and no ticket office. If I want to ride the train, and have not had the forethought to buy a ticket ahead of time, I must have cash on hand to buy a ticket on board. Otherwise, I need to find the nearest ticket office, which is in New Carrollton and a 45-minute bus ride away, or the second nearest, which is at Union Station and a 30-minute Metro ride away. Since I rarely carry cash any more, this becomes sub-optimal.

So I’ve been thinking recently about how MARC could improve this situation, short of putting Amtrak machines at all stops, which they seemingly do not want to do for whatever reason (or else they certainly would’ve done it by now.) Two approaches come to mind, both demonstrated by other commuter rail systems in the country.

The first approach would be to accept SmarTrip/CharmCard, as MTA does for local transit services. This is what Caltrain and Sounder do using the Clipper and Orca cards (the Bay Area and Puget Sound equivalents, respectively, of SmarTrip/CharmCard.) You tap a card reader when you board a train, and then tap again when you get off. The system calculates the appropriate fare and charges it to your card.

Advantages: There are lots of these cards in circulation; many people riding MARC already have one, and thus it would be one less thing to ask commuters to manage. MTA is set up to load commuter benefit funds onto these cards. SmarTrip/CharmCards are fairly easy to acquire these days, with machines in Metro stations, sales at Giant & CVS, etc.

Disadvantages: You have to remember to tap off. Caltrain handles this by deducting the maximum fare when you tap on, and then refunding some of it (assuming you’re not actually paying the maximum) when you tap off. MTA would have to do something similar. There would be some cost to MTA to install card readers at all the stations, as well as to give conductors the same card readers that light rail ticket inspectors currently carry. Unless MTA installs something like the light rail ticket machines at all stations, you’ll still need to load funds onto your card somewhere else, and if MTA can do that, why can’t they put Amtrak machines everywhere?

The second approach would be to have a smartphone app for purchasing electronic tickets. This is what the T does for commuter rail around Boston, and NJ Transit does for commuter rail in New Jersey. Amtrak also offers this across the system. Using these apps, you buy a ticket ahead of time, store it on the phone, and show it to a conductor when they do their ticket collection.

Advantages: Doesn’t require MTA to install any new equipment at stations. Lots of commuters have smartphones.

Disadvantages: Lots of commuters don’t have smartphones. Conductors need to be trained to recognize valid e-tickets and, depending on how strict you want to be, need to be equipped with handheld code readers to verify tickets (Amtrak does this; the T, as far as I can tell, usually does not.) Unless your e-ticket purchases are backed by an online account (they are for Amtrak and NJT, they aren’t for the T) you are screwed if you lose your phone. Cash purchases wouldn’t be possible. Loading benefit funds might be hard.

So neither of these approaches solves all the problems, but either one could work at least for the Greenbelt scenario. Greenbelt is a Metro station, so SmarTrip cards and reloads are readily available, and so the SmarTrip-based system is viable. I think I’d prefer that over the smartphone approach—having one card for all transit-related needs, and not needing to carry my phone (although I always do, anyway) seems like the best solution to me.

(Tangential to all of this is that SmarTrip/CharmCard’s days are numbered; eventually it’ll be replaced with a system based on contactless credit/debit cards and NFC, as is happening in Chicago and Philly. That’s a subject for another post, which I’ll probably write next year at this rate.)

Postscript

I wrote this article two years ago (as of the date I’m writing this sentence.) Nothing has changed for MARC in this department. (However, MARC does have new Bombardier bi-level rail cars, similar to those used on NJ Transit, so that’s nice.)

I neglected to consider a third approach, which is basically a combination of the first two: a smartphone app linked to a SmarTrip card. This is what Metra is going to do to join Ventra and thus make Ventra usable across Chicagoland transit. Metra had a page (which seems to be offline now) explaining why they didn’t go with my first approach above – basically, Metra has a lot of stations, and the cost to put tap-on/tap-off readers at each station would be prohibitive. In addition to allowing Metra tickets to be bought with Ventra, the app would also provide Ventra account management services and, eventually, permit you to use your NFC-equipped phone to pay CTA and Pace fares from your Ventra transit balance (as opposed to your credit/debit card balance, which you can do today – basically, it’d be like using your Ventra card without actually using the card.)

MARC has approximately 16 as many stations as Metra, so maybe the first approach wouldn’t be as cost-prohibitive for MARC. However, the current governor isn’t a fan of spending money on transit, so perhaps that’s irrelevant. Nonetheless, I like this idea of combining an existing smartcard infrastructure with an app. Perhaps WMATA and MTA can get together and come up with a plan, the humble narrator said, ignoring for the moment that MTA has to beg for money and WMATA has more problems than that Jay-Z song.