Review: The Engineering Dilemma, SimplyGo
Hi, Weiyuan here from Big O(n) Development!
We’re back on covering another interesting topic — the SimplyGo migration that occurred in Singapore, and the subsequent rollback 😄
It’s a 2 hour long (!!!) podcast, so here’s a summary of all of the essential details that went on in there!
Summary
As part of the podcast, we started by discussing the context of the SimplyGo migration, which was a next-generation EZ-Link card system taking over the preceding EZ-Link card system. The migration and planned discontinuation of the older system was fraught with pushback and negative feedback from the public, which eventually led to the overturning of the decision and continuing support for both systems for the time being.
Causes
The basis of the pushback by the public fell squarely into 2 areas:
- SimplyGo does not support motoring transactions at this point, creating increased inconvenience for its users
- SimplyGo was unable to show the fare at the train and bus gantries, something that the older system and systems around the world could do. This was a technical limitation for SimplyGo as the fare was not computed on the frontend (gantries) but on the backend servers. Hence, implementing this feature would lead to fares being reported but with higher latency than the older system, resulting in slower exits of passengers from MRT stations and bus stops, and worse user experience in a different direction.
Continuing the discussion, we talked about how this was an odd way to do an “upgrade”. There are definitely upsides for users adopting SimplyGo — such as eliminating the manual hassle of topping up the EZ-Link cards. On the other hand, the downsides are also alarming, as it took away the features mentioned above, some of which still face heavy usage by certain user groups.
Looking at past metrics and data
Next, we touched on the history of previous migrations, all of which were observed to have been concluded within shorter time periods of 8 months and 9 months respectively. This was much faster as compared to SimplyGo, which has had an overlap with its preceding system for 5.5 years (as of January 2024):
We discussed why this was so — perhaps this was an indication of the “writing on the wall”, where the long migration period was a precursor that not all users were not on board with these changes. While no software product and migration can be perfect at all times, better user and product research — whether in study groups, or product metrics, should be utilized if possible to serve the product and users better.
On a similar note, failures are eventual and not avoidable too. But to grow from setbacks is an essential ingredient for survival, and we express concerns that a postmortem should be done, both to understand what went wrong (root cause), and how to proceed forward (both for the short-term solution and the long-term plans).
Solutions
Lastly, we spoke about solutions, two of which we focused on:
Solution 1, Adopting a secure stored card standard, like Suica for Japan
Pros — Overcomes the latency issue for showing fare. More likely to be backward compatible with older systems, that also use stored-value cards. It is also a proven solution, as seen below.
Cons — Not a universal solution like SimplyGo, which can tap into the credit card infrastructure. Less friendly UX for non-residents who will need to purchase a fare card for traveling.
Solution 2, Simplified distance-based pricing, where fares are easily calculated by distance ranges (e.g. 0–5 KM, 5–10 KM, 10–15 KM, and so on), working across travel agencies universally (SMRT, SBS, Tower Transit)
Pros — If fare computation is simpler, prediction of fare can be easily done on MRT and bus gantries, which will be eventually consistent with backend computation. Supporting the above, gantries processing SimplyGo’s account-based card will just need a GET call to the backend to fetch the current account balance, which would have lower latency turnarounds as compared to computing the entire fare.
Cons — Pricing changes are not easy to enact, especially across multiple agencies. It would be hard to justify fair fare amounts in these ranges too. Pricing changes also do not solve the underlying engineering problems of the system.
Watch the full episode here:
