This year, for the A to Z Blogging Challenge I'm posting alphabetically on topics related to software development...
© Photographer Illreality | Agency: Dreamstime.com
So far, we've been pretty high up in the stratosphere, talking about architecture, business requirement, and core concepts. In contrast, this post can apply at all levels of design and development, but it is most at home down in the weeds of the code.
You reach a point in your program where you have a decision to make. A fork in the road. If the answer to a certain question is "Yes" you do one thing, if it's "No" you do something else.
The average programmer will likely code something that says: If "Yes" do one thing, otherwise do something else.
Notice the difference?
Where did "No" vanish to?
"What's the difference?" Average Joe-Coder protests. "It can only be yes or no, so if it isn't yes, it must be no. I'm just being efficient."
Sure, but you're not being defensive.
A defensive programmer will write code along the lines of: If "yes" do one thing, if "No" do something else, otherwise tell a bloody human that someone's f****d up!
"That's mad," Average Joe-Coder says. "Why code for something that can never happen?"
Fair point, if that were a true statement. But, despite Joe's insistence, it will happen ... some day. Trust me. You're relying on logic to ensure the only possible answers are yes or no, and that logic has been written by human beings - with all that implies. And computers are physical machines. They glitch sometimes. What went onto the disk as a nice clean "Yes" or "No" might overnight morph into "Whatever".
And, you might remind Joe, the more unlikely it is to happen, the more important it is to tell someone when it does.
If a stranger wanders into a public library, nobody cares. It's expected behavior, not a problem.
If a stranger wanders unchecked into the loading dock of the local supermarket, it's not expected, but plausible. There's no locked doors to stop it happening. A member of staff will likely ask, "Can I help you?" and it's not a big deal.
If a stranger walks unchallenged into the Queen's bedroom at Buckingham Palace, you can bet it will be a big deal and the authorities will want to know about it. Because that should be impossible.
But it has happened.
Defensive design makes no assumptions.
Face the unthinkable. Decide how to handle it, and act accordingly.
Thursday, April 4, 2013
Subscribe to:
Post Comments (Atom)
10 comments:
The part about the stranger in the Queens bedroom made me giggle quite ferociously... I wanna be that person... :0)
Bucket list item!!
Hugs!
Valerie
If it can't be YES it MUST be something else....there is ALWAYS something else.
" "
If the word is Yes, type "Y"
If the word is No, type "N"
But, what if there is no word?
:D
I love your theme! And those awesome examples.
Interesting concept! I've never thought of it like that before.
Informative posts. I absolutely love how crystal clear your examples make this concept.
I'm thinking this is where being creative and thinking of the unthinkable in that mode plays into the whole programming thing for you. :)
Valerie, you're naughty, but from what I've seen on your blog it fits :)
Delores, there is always something else...
Diane, that is the kind of question that should cause a business analyst to vanish in a puff of existential paradox :D
Donna, thanks, I love coming up with examples, as you'll see this month.
Karen, and the trouble is, many people designing software don't either.
DL, glad you think so.
Jean, strange, I think of it as straightforward pragmatic, but there's certainly loads of room for creativity elsewhere in the process.
Excellent theme!
Connie
Checkin' in from the A to Z Challenge.
Peanut Butter and Whine
Hi Ian .. love this - and you're explaining it all so well .. great post - the Queen's bedroom thing was a rum one wasn't it ...
Cheers Hilary
Post a Comment