Here's a gold mine that will pay out for years, perhaps decades. Let's nuke the mine and get an extra 1/5th on the first payout, sacrificing all future gains. Real smart there boys.
It's not the $7, but the principle
61–67 of 67 posts
Re: It's not the $7, but the principle
#62Earlier quoted context omitted.
"We have more pressing concerns than calling string.replace()" -- ? I don't think this particular case quite rises to the level of a "tradeoff." It's a single function built into just about every high-level language.
Last time I implemented a CC regex, it was a little more involved than just removing empty spaces. So you see... Your trite example fails to pass muster just as well. (Anymore, I'd just use one of many Stripe libraries... no fuss, no muss.)
or, if you can use a regex in a sane language replace("[^0-9]", "") then check for the length of the credit cards that you are using. shouldn't take a dev more than 5 min to code and test. Your argument is not really all that valid.
Re: It's not the $7, but the principle
#63Earlier quoted context omitted.
A lot of programmers are terrible at their craft.
And/or management that doesn't allow devs to spend time on user-friendly features.
In any case I can imagine it would take less or equivalent code and time to do a string replacement than handle generating and reporting the error. In my experience, it's primarily been inexperienced programmers.
Re: It's not the $7, but the principle
#64Earlier quoted context omitted.
Last time I implemented a CC regex, it was a little more involved than just removing empty spaces. So you see... Your trite example fails to pass muster just as well. (Anymore, I'd just use one of many Stripe libraries... no fuss, no muss.)
really though, it's not that hard to write a simple regex or few line replace command to make the form dead simple to use. creditCardString.replace(" ", "").replace("-","").replace(etc...) or, if you can use a regex in a sane language replace("[^0-9]", "") then check for the length of the credit cards that you are using. shouldn't take a dev more than 5 min to code and test. Your argument is not really all that valid…
Re: It's not the $7, but the principle
#65Earlier quoted context omitted.
And/or management that doesn't allow devs to spend time on user-friendly features.
Really? You think management is standing over the programmer's shoulder going "Whoa whoa whoa... the length validation was acceptable, but removing spaces for them? Simply indulgence . Just throw an error." In any case I can imagine it would take less or equivalent code and time to do a string replacement than handle generating and reporting the error. In my experience, it's primarily been inexperienced programmers.
Also, in some places you are not allowed to check in code without a ticket or req number. When you check in on your own you commit qa and others to support it, and other devs to maintain it. Big bureaucracy sucks but exists and sometimes even has good reasons.
This is a trivial example though, but you get my drift. I agree it sucks, just trying to explain how it happens.
Re: It's not the $7, but the principle
#66Re: It's not the $7, but the principle
#67Earlier quoted context omitted.
Maybe they had more pressing concerns? Perhaps they believe their time is better spent improving their product (providing more value) rather than automatically removing spaces in a credit card form? Maybe the OP was the first to find it particularly vexing / frustrating? All of these things are tradeoffs. Especially in small, young organizations... it's not reasonable or realistic to polish every single thing. In fac…
"We have more pressing concerns than calling string.replace()" -- ? I don't think this particular case quite rises to the level of a "tradeoff." It's a single function built into just about every high-level language.