Hacker News new | ask | show | jobs
by a_c_s 4299 days ago
The author, clearly not a developer, doesn't seem to see the potential for high cost in making a software change. This particular change involves training for all customer-facing employees and making a change to the software on each of the 20-year-old machines. Such a change would also increase the complexity of the software, of which I have the impression is already finicky and less stable than would be ideal.

I don't know how software updates are rolled out, but it wouldn't surprise me if a technician has visit each machine individually.

This isn't some trivial change to a non-essential web app, but rather a significant investment in time, energy and money.

The prudent thing to do would therefore be to roll many changes into releases and minimize the number of releases done.

Given how few people this issue affects, I'm glad the MTA is pushing this off: I'd actually prefer they didn't fix this issue.

---

Also, to argue that this affects poor people the most while arguing that an acceptable solution is to make a change exclusively for people who use credit cards illustrates having a minimal understanding of poverty.

---

Finally, judging agreement by how many hits you get is an absurd thing to do.

7 comments

> The author, clearly not a developer, doesn't seem to see the potential for high cost in making a software change.

I see this kind of reply often, but I don't think it's the right approach: "We are sorry: what you are saying is correct, but we won't fix it because it's hard to do. Next time, try to complain about the easy fixes".

I don't think the customer should be required to be an engineer before noting that something is wrong, nor the company should be able to use its own deficiencies as an excuse about why they won't solve it. And particularly not in the case when the company is directly benefiting from its own incompetence.

> I don't think the customer should be required to be an engineer before noting that something is wrong, nor the company should be able to use its own deficiencies as an excuse about why they won't solve it.

I think you misunderstood his point. He was calling out "why would you wait for a fare increase to do that" as being naive, not "this is a problem that needs to be fixed".

Nothing wrong with calling out the problem as needing to be fixed, just saying that making two changes at once is vastly superior to trying to make two sets of changes in these situations.

Absolutely 110%: people can should raise concerns without knowing their complexity.

The problem comes in when these same people make uninformed proclamations of how easy or simple things are to fix.

Do you honestly think that hundreds of machines capable of authorizing simultaneous credit card transactions and synchronizing mag stripe cards against a central service all receive a price update through direct manual access?
I live in NYC. It wouldn't surprise me if these machines require direct access for an update, however these machines are serviced >all the time<. Apart from anything else, they need to collect the cash from the ones that accept it, so it's likely that on a given day you'll see a couple of armed MTA employees with a machine open messing with it.
Remember this system was rolled out in 1993, meaning any hardware/software combo started development before that. So the question is: do I believe it likely that a system developed before the internet became widespread has an archaic, non-networked way of handling software updates?

My answer is yes.

(Though for the sake of whomever maintains the system I'd certainly hope to be wrong about this! Either way, an update to all of these machines is likely not the trivial change the author presumes it to be.)

I would expect this change to be easier than you say. If they increase fares, I am pretty sure they are able to set the new fares overnight on all their machines and not have a delayed rollout schedule. Imagine the chaos of they couldn't.
Twenty year old machines? I would certainly believe it.

Also you would want to test every machine that gets the update in either case, so you need some kind of tech to touch every machine.

Maybe they can be fully updated remotely. But let's think about this...is that really such a good idea? Can we trust subway card machine software to be fully secure against malware and remote exploits?

Maybe it's better if the network interactions of these sorts of machines are strictly limited to operational transactions. Maybe it's better if it does takes a human being with a key, guarded by a cop with a gun, to update this software.

I was going to ask that as well. Thanks!
Small point, but the MTA vending machines are not 20 years old. They are among the newest most usable touchscreen devices I've encountered. Bright sensitive screens with large touch targets.
>The author, clearly not a developer, doesn't seem to see the potential for high cost in making a software change

Agreed, one should be fairly close to the dev team before coming up with estimates. Other red flags: "government agencies" & "So the MTA could make a small software change that only applies to the Credit Card Only machines with limited effort"

It's a price change! They don't reprogram cash registers each time a price changes. (On a side note, I do happen to be a software developer!)
It is almost certainly the case that there is no readily available mechanism for easily changing the price on credit card only machines without changing it on cash + credit card machines. Presumably changing the default pricing structure would have to change both, which would cause the problem that either a great many machines would suddenly be providing $0.95 worth of change for everyone paying with a $20, or everyone would need to start carrying around nickels.

Clearly it is more work than a simple price change to create a new user interface that asks whether you're going to be using a credit card or not before displaying the prices.

I find it very hard to care about what author is trying to say because he sounds so condescending. However, I do understand his confusion somewhat.

It had been a longstanding pattern in software engineering to gradually simplify UI. As a result a lot of UI's are simple and people are assuming underlying systems are simple as well. In majority of the cases that is not true and simple UI is produced by highly complex underlying software. Confusion comes from the fact that people look at the UI and think this is simple, you just need to change this number there. When in reality you need to change an underlying system and that change could range from trivial to rewrite entire system in complexity.

visiting every machine is trivial; it occurs daily/weekly for all cash-accepting machines in order to get the cash. This is also not performed by just one low-paid employee; it is typically performed by two people, one of whom is armed and has his weapon drawn. So there's no issue sending out trained personnel to every machine, it happens every day.

Where there is an issue here is that if the software change only applied to credit card sales, there would be an accusation that the machines now favor more affluent customers who can afford to own credit cards.

The people who collect the cash are probably not the people who install, test, and verify software updates.
Uh, look at the screenshots, there's a "single ride" option.

Now figure out why your comment's wrong as an exercise in getting better at gathering requirements. Hint, they have to do something to all the machines every year or two...