| 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. |
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.