My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
The other day I went to a major pizza chain's website to order online. I had to create an account first, of course. No big deal.

As I was choosing my password, I was pleased to see a password strength indicator to the right. Excellent, it's telling my password is "too short" -- let me add some more characters. "Warning: Too Simple" it said. Great - now I'll add some numbers in there. My password strength was now "good," but since they were going to be storing my personal details, I wanted a "great" password. I like to throw characters in there that aren't letters or numbers, so I did. And it told me my password strength was "great."

Even better that they gave a color indication as well - going from red to green as my password got sufficiently strong.

You can imagine my disappointment when I hit the "Go" button, only to be presented with this message:
Please enter a valid password. Valid passwords must be at least 8 characters in length and contain letters and numbers only.
elite hacker skills blocking your secure and keeping your passwords safe from special characters

Look, I understand the allure of arbitrarily limiting these things. You secretly want someone to put in those special characters just so they can see how good you were to have the foresight that someone might try to use one.

When I first started programming for money I did the same thing. Even though we were on a modern OS with very few limitations on filenames, I wrote the application such that it would enforce MS DOS filename restrictions, and only allowed letters and numbers. I spent extra effort to make sure the application would fail on completely valid input.

As a consequence, strange bugs pop up because that app is not the only interface, and the system is less usable for the customer.

I know most of you in this audience already know you shouldn't design "features" like this. But for the newbies that haven't yet had enough experience to know: If you don't have a valid reason for constraining the data, don't do it just to show off what you can do.

It's an annoyance at best. It adds complexity where none is needed, making your application harder to maintain over time. At worst, it results in defects that your customer paid you to insert into the application. And that's a tragedy of ethics.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner