Live data from Hacker News

It's not the $7, but the principle

antti.vilpponen.net

61–67 of 67 posts

Re: It's not the $7, but the principle

#61

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.

Someone downvoted me. Probably didn't get the analogy, so I'll spell it out. The gold mine = a subscriber. The nuking of said mine = fleecing the subscriber on his/her first payment and thus losing the subscription.

Re: It's not the $7, but the principle

#62
post #60

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

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

#63

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

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.

Re: It's not the $7, but the principle

#64
post #60

Earlier 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…

That's exactly what I do whenever I expect a number like this. For instance, phone numbers... Normalize them by replacing all non-numeric characters /then/ validate them. I can't imagine trying to validate the hundred different formatting variations for phone numbers.

Re: It's not the $7, but the principle

#65

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

Not exactly. Typically it would be to keep them so busy as to never have time to get to it. If you don't actually use the feature it's not gonna be a priority.

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

#66
It might be a bug, but the networksolutions.com checkout process also acts opportunistically when you add a domain to a new account. It will ask if you want to 'auto-renew the purchased domains AND all others you previously purchased'. If you change the setting to 'don't auto-renew' and then make a validation error (miss the terms of service checkbox), it will keep state for all other fields, but magically the auto-renew value switches back to the default.

Re: It's not the $7, but the principle

#67
post #56

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

I completely agree that the user's experience of using a form should be well thought out, and that error messages like "please remove spaces" shouldn't be part of any well thought out form, but suggest that anything is free of trade-offs is absolute nonsense. That `string.replace()`, along with all the others for all the other things your well thought out form does the thought-at-the-time-to-be-right thing with open the door to both bugs and user confusion. It's worth it, but it isn't free.
Post reply on HN