The Bourne Legacy Disappointment

I was quite disappointed in the movie.  It isn't bad and it sets up what should be a few good movies down the road, but was just disappointing.  Here are some the reasons why:

SPOILER WARNING
SPOILER WARNING
SPOILER WARNING

1) It's all about the drugs

After Aaron Cross nearly gets killed in the beginning of the movie, you think he might want to get revenge on his handlers?  Nope.  What does he want?  Drugs.  I couldn't help but think during the the movie that badass Aaron Cross is just a junkie, "Where are the chems?", "Do you have any chems here?", "How can I get more chems?".

Similar to the "midichlorians" in Star Wars, the drugs also removed some of the allure of the Treadstone/Blackbriar programs.  Rather than brainwashing and training the agents, are they just druggies?

2) Aren't spys supposed to be secretive

During the end chase, the Larx-3 agent punches a bunch of citizens and attacks cops.  He does it multiple times.

I thought these guys were supposed to be spys and hide and be "ghosts" (I think they were referred to this in the first movie).  Now this isn't to say that Jason Bourne didn't get the attention of the police, but he did seem to make a number of attempts to not get engaged.  In the Bourne Ultimatum, the asset kills Simon Ross via sniper rifle.  Larx-3 could have done the same thing too, but he decides he wants to chase them on foot.

3) Where's the super spy fight

Every Bourne movie to date had a cool fight between Treadstone/Blackbriar agents.  No fight in this movie.  In fact, Aaron Cross had a little trouble against the normal agents he fought in the house.  I was just waiting for him to fight Larx-3 at the end of the movie.  Only to find Larx-3 was taken out by wiping out on his bike.

This is how you lose a sale Best Buy

There have been numerous articles written about why Best Buy is losing business (I recall reading "Why Best Buy is Going out of Business...Gradually" recently).

Today I went to Best Buy to buy a tablet.  I had my credit card ready and was going to make a purchase.  All I was debating was which one I wanted.  Most importantly I wanted to try out some tablets to see if the ~7 inch tablets would be good enough for me or if I needed one of the ~10 inch ones.

Several of the floor model tablets were broken, prohibiting me from trying them.  When I alerted the staff, they apologized, saying that someone had broken one of them several days earlier.  I'm like, "But I can't buy one until I can try it."  He apologized again ... and that was that.

So this is how you lose a sale Best Buy.  I ended up wandering into a Verizon store and was able to try out the tablets I wanted to try.   Verizon would have gotten the sale if they carried the WiFi only versions, but they did not.  I guess I'll pick up the one I wanted at Frys or maybe I'll just buy it on Amazon.

Vendor Communication Frustrations

It's common for me to find firmware bugs on vendor hardware that interacts poorly with software written in house.  My assumption is that vendors sell their software as a "value add", only test their hardware with their software, and have limited care for third party software.  Once in awhile the vendor fixes hardware issues in their software, so the issue is technically in the third party software, but it's not the third party's fault.

When I report a bug in the firmware, it's common for a vendor to respond with something akin to, "It works for our software, it must be your software."  It's a normal, yet frustrating, response.  In addition, to get the problem resolved often means getting through layers of support before reaching an engineer that understands the situation.

Over time, I've come up with a few mechanisms to handle this type of issue with vendors more quickly.  Here are some of them:

A) Add packet dumps or equivalently "advanced" debug information in the ticket.

I'll add information to the bug that is reasonably complex or difficult to understand.  The common example is something similar to a TCP packet dump.  I add something in the ticket with arrows (e.g. "See here --->") and something like "this 0x8 should be an 0x5".

Due to the complexity of the information, the ticket is typically passed up the food chain more quickly.  In addition, it sometimes does not matter what software was running to generate the TCP packet dump.  I can just say it was their software, they would never know.

Ironically, I sometimes have nicer/better debugging information (or even the flat out solution) I could put in the ticket.  However, I often elect to put the more confusing information in the ticket b/c it ultimately resolves the problem more quickly.

B) Be very specific in your requests

It's better to ask for very clear specific information.  A normal request might go like this: "I noticed an OEM piece of information on your motherboard.  Can you please describe what this means?"

While this is a perfectly reasonable request, it leads to the wrong answers.  A common answer might be, "Use our software X, it can show you all the information", which is of course not a useful response.  Or you might get "That information means FOO, you need to do BAR for your system", which might be true, but isn't what we're really looking for.

It's better to be very specific with your request, for example  "I noticed the following OEM piece of information: 0x20 0x18 0xA2.  What is the mapping of OEM hex to English.  0x20 = ???, 0x18 = ???, 0xA2 = ???."

C) Site standards/specifications that can't be challenged

I'll site standards/specifications, making it clear that if they wish to counter my claim, they will have to know what they are talking about and prove it to me.

For example, I might write, "Please see the following packet dump.  Clearly the X field violates section 1.2.A of the specification, second paragraph, third sentence."

This type of statement is so specific and advanced, it will typically skip lower support levels.

How Coding WTFs Happen

I love to laugh at the coding gaffes on TheDailyWTF, but I know that I shouldn't laugh, because I know the coding gaffes could happen to me by chance.  I saw a code snippet like this one awhile back in code I work with.

switch (val)
{
  case ENUM_A:
    do_A();
    break;
  case ENUM_B:
  case ENUM_C:
  default:
    do_default();
    break;
}

I remember this pretty clearly b/c I know exactly how it reached this point.  The code used to be like this:

switch (val)
{
  case ENUM_A:
    do_A();
    break;
  case ENUM_B:
    do_B();
    break;
  case ENUM_C:
    do_C();
    break;
  default:
    do_default();
    break;
}

However, as code was condensed and options eliminated, people removed only the portion of code that was necessary to remove.  Only after looking at the code from a distance does someone finally realize this should be condensed to something far more reasonable (and removing the unnecessary enums too):

if (NEW_BOOL_FLAG)
   do_A();
else
   do_default();