My wife and I picked up a friend from the Ottawa airport the other day. On our way out, we had to pay for parking at one of those booths with a mechanical barrier. Only when we paid, the barrier didn't go up. The attendant looked at us funny, saying: "Ok, you can go now", and we looked at him with an equally funny look saying: "Sure, just lift the barrier first".
After a few iterations of this, including the attendant's assurance he had pressed the right button (and hence the gate should be up), he realized maybe we weren't making it up (he's facing the other way) and told us he had to call someone else to get it open. That someone else eventually showed up with a set of keys and a screwdriver-like tool, which he proceeded to use to open up the mechanical barrier's box. This got the barrier to lift, apparently mechanically.
The RISKS? Well, you'd hate to have the power go out or have an emergency of some sort, since it can obviously fail. Those gates should use a mechanical assist -- thus allowing a human being the option of lifting the barrier themselves -- instead of a completely mechanical drive, just like most garage door openers have that dangling string you can pull on to switch to "manual mode".
Since this blog is about software, ummm... the lesson is the same! Always provide a manual option or an override in software. It's no coincidence computers in movies always have an "override" option (although it's admittedly unlikely those people can somehow always get authorization to do so), but the message is clear; there's always a special circumstance where normal rules/validation conflict or aren't appropriate and thus should be temporarily disabled.
That is, if you want your software to be used. After all, business must go on and if the software refuses to accept unusual input (especially as the business evolves), then people will work around the software and use it less and less.
So think about this issue the next time you need to implement some sort of validation and make it more like guidelines.
3 comments:
"So think about this issue the next time you need to implement some sort of validation and make it more like guidelines."
That's well and good unless declared busness rules dictate that input MUST be constrained by XYZ. Of course you & I know that business rules can (and do!) change, however if you don't implement to spec, you won't pass user acceptance.
Homework: How would you implement a more "guidelines" approach when faced with strict validation requirements?
It depends on the [nature of the] business, but if there's an instance where it makes no sense to constrain the input "by XYZ", then the business rule is wrong and although it would conform to the specification (which is thus also wrong) and pass "user acceptance" (still wrong, by transitivity), it wouldn't pass real-world use, which is what really matters.
CONTACT: onlineghosthacker247 @gmail. com
-Find Out If Your Husband/Wife or Boyfriend/Girlfriend Is Cheating On You
-Let them Help You Hack Any Website Or Database
-Hack Into Any University Portal; To Change Your Grades Or Upgrade Any Personal Information/Examination Questions
-Hack Email; Mobile Phones; Whatsapp; Text Messages; Call Logs; Facebook And Other Social Media Accounts
-And All Related Services
- let them help you in recovery any lost fund scam from you
onlineghosthacker Will Get The Job Done For You
onlineghosthacker247 @gmail. com
TESTED AND TRUSTED!!!
Post a Comment