[pwg]

From the article: " I entered my credit card number with spacing like 1234 1234 1234 1234 and all the other information as necessary. After I clicked “Submit your order”, the form returned an error and asked me to fix the credit card number so that there are no spaces ..."

Why do so many web developers insist on forcing me to enter a 16 digit number _without_ spaces when a computer is excellent (and fast) at removal of spaces and I am not so good at validating I've typed a 16 digit number correctly when that number lacks the spaces?

[weaksauce]

A lot of programmers are terrible at their craft.

[mixmastamyk]

And/or management that doesn't allow devs to spend time on user-friendly features.

[nucleardog]

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.

[mixmastamyk]

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.

[tel]

And "programmer" means many things, even once hired and working.

[beambot]

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 fact, not focusing on this particular element probably aligns with pg's #1 "hardest lesson for startups to learn": http://paulgraham.com/startuplessons.html

EDIT: In this case... it's talking about FastCompany, so "startup" probably doesn't apply. But most journalism companies are really hurting right now, so allocating resources is still probably problematic. The shady customer service is the more damning thing.

[FreakLegion]

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

[sanderjd]

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.

[beambot]

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

[weaksauce]

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.

[nucleardog]

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.