Monday, November 30, 2009

Difficult Santa talk...

We took time this evening to rearrange the living room and prepare the Christmas tree for its decorations.  It's a tree of wire and plastic that needs 'adjusting' to give it a more tree-like appearance.  John found this adjustment period to be rather tedious which led him to frequently inquire whether the job was complete.  One of these inquiries led here...

John:  "Are we done yet?"
Daddy:  "Not yet, you know why it's important to spend time adjusting the tree don't you?"
John: "Yeah, so that we'll get lots of toys under it."
Daddy: "Well, not exactly.  The more time we spend adjusting it, the more beautiful the tree will ultimately look."
John: "Right."
Daddy: "Besides, shouldn't we be grateful for any toys that we might find under this tree, be it one toy, or lots of toys?"
John: "Yeah, we should be grateful for whatever we get."
Daddy (who should have simply stopped):  "That's right... you know... there are many kids who won't get any toys this year, so, even one is better than none, right?"
John: "Well, yeah, those are the naughty kids, right?"
Daddy (who only now is starting to realize he should have stopped talking already): "Well, some are naughty, but other's have parents who simply can't afford toys this year."
John:  "But Daddy, Santa doesn't treat kids without money differently does he?"
Daddy: "Well, no.... ummm... "
John:  "Daddy, this is sad news, I think we should go shopping tomorrow for those kids who aren't naughty."

Friday, November 20, 2009

FAQ on the first date?

I follow Jeff Atwood because I think he's generally a bright guy and so I took notice when Adrian (another bright guy) was critical of him.  Then, in following a link from google today, I notice this at the top of my browser...

This is from Stack Overflow, Jeff's brainchild.  For an otherwise bright guy, what a incredible dumb thing to do, amateurish really.  Here's why:

o) It seems to pop up based on whether your signed in or not; rather than whether it's really your first time.  It is not my first time, so it's annoying to see it every time.

o) Let's suppose though, that it were my first time.  I doubt I'd have a frequently asked question already.  If I did, would it not be an indication that your site really kinda sucked?

o) Lastly, there's the presumptuous nature of the popup itself.  You really think anyone would want to sit and read your FAQ on the first date?  You're crazy.  You get me hooked on your software and then when I have a question I may poke around your FAQ, otherwise, I'll just leave.

The bottom line...  if a question is asked frequently enough to make it on your FAQ list and said question is of interest to a first time visitor, it's time to fix your software...

Sunday, November 15, 2009

Geocaching woes...

"Geocachers find trinkets and trouble" (WashPost)

Sounds all too familiar. At least these people are in Loudoun, Va. Paulding County, Ga., not so understanding.... I don't recall the exact conversation but it went something like this...

Ranger: "You boys been walking around in circles looking at that thing for a long time now..."
Us: "Yeah, it's a GPS unit for land nav trying to find a location"
Ranger: "What's that you got there? a G-P-S (overly drawn out)?"
Us: "Well, it's just a GPS unit, like a digital compass... you know..."
Ranger (skeptically): "I don't know, this just don't sound right"
Ranger (incredulously): "And you say you're looking for some kinda 'treasure'"
Us: "Well, kinda, see, people hide stuff and it's fun to go find it."
Ranger: "Ain't nobody supposed to be hiding stuff on my park land. Anyway, how am I supposed to know ya'll ain't some sorta terrorists or something? these are dangerous times, you know? What exactly are they hiding?"
Us: "Usually, it's just little toys, trinkets, a notebook, and whatnot."
Ranger: "And so you're using some sorta navigation computer to find toys out in the woods?"
Us: "Well, yeah, it's just sorta a game, you see, well, maybe we'll just go now."
Ranger: "Yeah, maybe you should, I don't expect I'll see you back here, right?"

It was longer and even more ridiculous of a conversation than that - would have been good sitcom material. It ruined the hunt - we felt ridiculous. But, it was a learning experience. We learned that such folks are called Muggles and are to be avoided....

Sunday, November 01, 2009

Architectural Styles, Constraints, Desired Properties, etc.

REST gets all the attention, but I think the framework presented in the first half of the dissertation is equally, if not more, important.  There are many frameworks that attempt to understand software architecture but none that I've found that are reasonable.  REST itself is a derived by way of a worked example through that reasoning framework.  I'd like to start using that approach myself but doing so demands a common understanding which, as with REST itself, is rather elusive.  Trying to explain it, as Roy did, in technical terms is further burdened by preconceived notions of overloaded terminology.  So, I crafted a story that attempts to communicate the essence (constraints, desired properties, architectural styles, etc.) without being burdened by the baggage of assumptions.

The story goes like this...

Suppose a customer comes to your "information business" and says, "I have a need for all the information on organic gardening."  The customer travels a lot and needs the information available to him for reference when his customers ask gardening questions, but he's frequently in the fields and, so, isn't always technology enabled.

Your organization is quite large and information comes from a variety of departments.  To make matters worse, you're in the Solutions Architecture side of the business and so you have no real authority to dictate a precise solution - these are 'information engineers' after all, who need room to flex their creativity.  You are, however, allowed to define the solution architecture by way of  "constraints" on their solution.  These "constraints" take the form of:

1) All the information must be together.
2) There must be a Table of Content.
3) All information must have a reference back to the original source.

You have done this so often though, that you and these engineers have agreed that these constraints can be grouped together and referenced by a simple name, its architectural style name, instead of enumerating each one every time.  This is beneficial because you know that certain constraints, when grouped together, evoke certain properties that are commonly desired by your customer.  This allows you to quickly match up your customer's needs with some starting constraints.  Now, you've previously agreed that constraints 1+2+3 above will be referred to as the Compilation Architectural Style.

It turns out that the constraints of the Compilation Style are a good starting point but they don't evoke all the properties that your customer really wants. They want something that's lightweight because they travel, they want something that's easily readable, and they also want something that doesn't require electricity/technology.

So you begin with an instance of the Compilation Architectural Style and add some concrete constraints to get you from "style" to a real architecture and evoke some properties specifically desired by your customer.  Namely, you add the following:

A) Compilation Architectural Style
 - evokes all properties known by the style
B) Information must be on paper
 - evokes lack-of-technology property
C) Information must be printed in Times New Roman
 - evokes readability property
D) Must be in a thin plastic binder
 - evokes lightweight property

So, you pass along the customer order and your solution architecture to the engineers.  Because you've chosen to define your solution architecture in terms of "constraints that evoke properties," you're able to objectively reason about them.  So, when the engineers come back and say that they'd prefer Helvetica because, being sans-serif, it would save on toner cost, you can reason about how changing this constraint might effective your overall solution architecture.  In this case, that level of font-specificity was simply you trying to flex some control where you have none, so you acquiesce. Likewise, the engineers come back and ask that you change constraint D to heavy-weight paper since it'd be a bit lighter - you, again, agree that it still evokes your desired property.

You deliver your solution, which makes your customer happy.  But then you realize that you ought to capitalize on your latest back and forth with the information engineers.  So, you go to the engineers and agree to call constraints B+C+D the Paperback Architectural Style.  In future requests like the original, this allows you to simply refer to a hybrid (Compilation Architectural Style + Paperback Architectural
Style) solution architecture and know that the desired properties will be evoked.