Refactoring is a legitimate strategy in software development. It’s where you feel the design is (more-or-less) right, but the software implementation has gone wrong, and needs to be completely cleaned-up, by chucking it out and re-writing it.
So here’s a thought: if the single most annoying, unreliable, sluggish part of the Myki system is the Readers, then how much time, money and effort would it take to completely refactor all of the software in the Readers?
Don’t change the hardware and cards, which has cost a bomb to buy and install, but (assuming the protocols the Readers work with is okay, and the hardware/cards are up to scratch – they’re used in other cities, after all) upgrade the software.
First you’d tweak the rules/logic a bit to help fix the worst issues — for instance, you might:
- ditch the confusing and not-very-good-value 7-day passes and replace them with an automatic weekly cap
- allow travel on a zero balance (rather than $0.01) to get around issues when people load the exact fare onto their card
- and you’d want to change the beeps to remove the meaningless double-beep and instead have differentiation between touch-on and touch-off
Then you’d hire a small team of gun programmers and testers, and let them get to work, with a small budget of say $1 million (about a 50th of the annual cost of running the ticket system) and some specific targets, starting with:
- fixing known bugs
- maximum 1 hour from online topup to it being available at fixed (railway station) readers
- and the most important one: consistent maximum 0.5 second response times (but preferably closer to 0.1 or 0.2), as seen with other cities’ smartcards
As my friend Josh often says: How hard could it be?