Just for reference: I hardly ever call code "garbage". But this is code that does (or is supposed to) run debit card transactions. I can't post it here (closed source), but the following problems have been observed in prodution systems:
- Timeout mismatches. The code marks transactions as failed even when they went through, with the effect that debit cards were double charged.
- Transactions that don't time out at all, forcing the user to restart the cash register.
- Working on the wrong transaction, with the effect that the customer gets charged the incorrect amount.
- No handling of child process exits, leading, again to forcing the user to restart the cash register.
- Not restart safe. Restarting the cash register (reboot, power loss, etc) while a transaction is in progress can lead, again, to the process working on the wrong transaction, charging the customer the wrong amount.
- A temporary connection loss of connection to the cloud server of the debit terminal provider again can lead to the transaction marked as failed (when it was processed successfully on the provider side), potentially leading to again double charge the customer.
In many cases i can be somewhat lenient about bugs. And as long as the software just crashes and can cleanly restart, nothing will go wrong - this case is already handled by my service manager software. Not good, but we are taking about a downtime of a couple of seconds of a background service, something the user will hardly notice if at all.
But when you are developing software that is dealing with other peoples money (in our case, the customers of our customers), "move fast and break things" is absolutely in no way acceptable. It has to work. Perfectly. Each and every time.
If there is a chance greater than one in a million transactions that a specific error happens, the software needs to handle that error correctly. After all, for busy shops such a "rare" error would at least happen every couple of years. Multiply that by a large number of customers. It's the curse of scaling. And it can easily turn into a PR nightmare, especially since people are trusting that their debit and credit card transactions just work. And, oh, if the problem keeps happening, one can easily loose certification by the debit/credit card terminal provider, which is an even bigger quantum leap in "oh shiiiiiit!".
In cases of critical code like this, frankly, one small bug is a disaster. Multiple large bugs that amplify each other is what made me declare that piece of code "garbage".
| [reply] |
that adresses exactly zero of the questions raised
| [reply] |
who's going to maintain your reinvented wheel
That is exactly the same question i have. For all modules, both the ones developed in house and the ones maintained by a third party that i just download from CPAN.
and will they end up calling your code "garbage" too?
Maybe? But that hasn't happened in the last decade or so.
Mojo::UserAgent
No. It doesn't fit into the way my cyclic executives are designed (which i have used in producion code for 15+ years).
And Mojo::UserAgent has an astonishingly ugly syntax, looks like JavaScript. Yes, i develop in JS, too, and yes, i am forced to use Promises, and yes that's also an ugly syntax.
Happy?
| [reply] |
