Sunday, October 19, 2014

The Power and Subtlety of Spin

I've written before about how pervasive 'spin' is today.  But I just happened to read more about it in You Are Not So Smart by David McRaney.

In the chapter entitle "The Misinformation Effect," he discusses an interesting experiment conducted in 1974 at the University of Washington.  Participants watched a video of a car crash and were then asked to estimate how fast the cars were going.  But the participants were divided into groups and the phrasing of the question was different for each group.  These were the different variations:

- About how fast were the cars going when they smashed into each other?
- About how fast were the cars going when they collided into each other?
- About how fast were the cars going when they bumped into each other?
- About how fast were the cars going when they hit each other?
- About how fast were the cars going when they contacted each other?

Remember, everyone watched the same video.  The only difference is the wording of the question.  Here are the average answers for each participant group:

- Smashed: 40.8 miles per hour
- Collided: 39.3 miles per hour
- Bumped: 38.1 miles per hour
- Hit: 34.0 miles per hour
- Contacted: 31.8 miles per hour

The experiment then went a step further.  The participants were asked if they remembered broken glass in the video.  There actually was no broken glass, but the participants with the 'smashed' question were twice as likely to remember seeing it.

I was floored when I read this.  Changing one word in a question can have a powerful impact on what people believe.

Once you understand this concept, you start to see it everywhere.  Right now, the big news topic is Ebola.  But what phrases are used around it?  Those phrases change your view of Ebola, regardless of the actual statistics and facts.  Is it possible that the individuals using those phrases are intentionally taking advantage of this effect?

Of course, it's much harder to notice this when what you're reading or hearing agrees with your own stance on the matter.  But that's Confirmation Bias and another topic entirely.

The point is, words have connotations.  Those connotations make an impact on what we believe.  Remember that the next time you watch Fox News.

Tuesday, September 16, 2014

How to Get Reasonably DRY

It's a presentation

Sunday, September 7, 2014

Chasing the Latest Trends

I'm an engineer.  I love playing with the newest toys.  But acquiring those toys has a cost - and not just in terms of money.  More important is the time invested to learn the new system and transition from the old.

But hey, for me, the benefit (fun) usually outweighs the cost (money/time).

A problem can arise, though, in domains where the technology is changing rapidly.  In such a domain, the technology could potentially change so rapidly that if you keep up with everything, you are constantly in a learning mode and never get to a productive mode.

I'm going to go out on a limb and say that is what is currently happening with HTML and JavaScript libraries.

One large-scale web application I worked on started with the Prototype library (heh, yea).  In mid-project we switched to OpenRico (remember that guy?).  Then we said, "Oh hey, the newest thing is MooTools."  Then there was the big one, jQuery.  Backbone?  Oh, Angular is so hot right now.  But what about Google's new Polymer?

Granted, it's exciting to see the evolution of the web platform.  But if you spend all of your time moving your project to the latest, hottest library so that you can trash talk all of the old fogies who still use the passé crap, you'll never be able to get any real work done.

But, come on, we can't still be coding in Cobol, right?  Nobody wants to spend their whole career working on old technologies.  Definitely!  So how do we decide if we should stick with something old or jump to the new kid on the block?

Nassim Taleb (author of The Black Swan) gives the answer:

The longer a certain idea or technology has been around, the longer we can expect it to survive.

He uses the example of a chair.  We may imagine the future with chairs made of exotic materials that fly.  But the simple wooden chair has been around for thousands of years.  Chances are, in 50 years, we will still be sitting on simple wooden chairs.  Why?  They have proven their effectiveness.

In terms of software, "future-proofing" is very very hard to do.  But applying Taleb's principle can help us.  For example, raw HTML has been around for a long time and so will likely stick around a long time into the future.  So maybe we pick a library/framework that is as close to raw HTML as possible.

Another example: Relative to other JavaScript frameworks, jQuery has proven its effectiveness over a good span of time.  Sure, there will be a new king someday.  But it's prudent to wait and see who can prove more effective over time.

How long is that time?  I don't know the answer to that; but I'm sure it varies by domain.

Again, as an engineer, this 'waiting' is against my natural inclination.  I want to get the new toy asap.  But if I'm responsible for a piece of software that my company will be maintaining years from now, I must force myself to make prudent decisions.

 
 

Monday, August 18, 2014

Why Ideas Come to You in the Shower

Scott Adams, the creator of Dilbert, is a surprisingly insightful guy.  I've been following his blog for some time and I read his latest book.  If you like thought-provoking stuff, I highly recommend them.

He just made this post about creativity:

http://dilbert.com/blog/entry/creativity_hack/

There have been several articles floating around the web lately about how inspiration comes to us when we take our mind off of the problem.  For example, this one.

The idea always goes something like: "you have to let your subconscious work at the problem."  That sounds reasonable, I guess.  But it doesn't go far enough.

Scott posits that "creativity is something that happens naturally so long as your brain is not actively suppressing it for some sort of survival advantage... Putting it in simpler terms, creativity is a mental luxury that your brain will not allow until it feels safe or until the watchdog part of your brain gets busy handling some routine task such as driving the car."

He goes on to suggest that research (A-B tests) should be done to determine which distraction methods yield the most creativity.  I suppose the challenge here would be how to quantify 'creativity.'  But I'm sure that, at the very least, we could measure some proxy for it.


Thursday, July 31, 2014

Digging for Requirements

I'm again going to refer heavily to The Pragmatic Programmer.  In fact, the title of this post is one of the sections in chapter 7.

Here the authors mention that the term 'requirements gathering' is misleading.  It somehow implies that the requirements already exist somewhere and just need to picked up.  Instead, they say requirements need to be dug for.

Users understand their workflow, but not in the same way that an engineer needs to understand it.  A user doesn't particularly care how much of his workflow is defined by the system architecture, company policy, laws of the country, industry standards, or even habit.

But an engineer cares.  He cares because some of those factors will change faster than others.  Some don't even need to be factors anymore.  So the system that he builds has to be flexible enough such that the more changeable factors can be accommodated easily.

It's important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it.  At the end of the day, your development has to solve their business problem, not just meet their stated requirements.

The above quote hits the nail on the head: the stated requirements are usually not the actual system requirements.  Hence there is a need to dig down into those stated requirements, find the real system requirements in there, and consider the rest as configuration options.

Here's the example the authors use.  Let's say a stated requirement is: "Only an employee's supervisors and the personnel department may view that employee's records."  It sounds reasonable enough, but it embeds company policy, which can change often.  Digging around that stated requirement reveals the actual system requirement: "An employee record can only be viewed by a nominated group of people."  Who comprise that group is simply a matter of configuration... the code doesn't care.

It's arrogant to say that an engineer understands a user workflow better than the user himself.  However, the engineer obviously must understand it from a system architecture perspective.  And since that is something users would never need to think about, stated requirements will almost always need some digging done.


Friday, May 23, 2014

The Fermi Paradox

"You know when you hear about humans of the past debating whether the Earth was round or if the sun revolved around the Earth or thinking that lightning happened because of Zeus, and they seem so primitive and in the dark? That’s about where we are with this topic."

http://waitbutwhy.com/2014/05/fermi-paradox.html

There's something terribly exciting about looking at a problem like this.  "...whatever the truth actually is, it’s mindblowing."

Sunday, April 20, 2014

Don't Think Outside the Box

Gordius, the King of Phrygia, once tied a knot that no one could untie. It was said that he who solved the riddle of the Gordian Knot would rule all of Asia. So along comes Alexander the Great, who chops the knot to bits with his sword. Just a little different interpretation of the requirements, that's all… and he did end up ruling most of Asia.

Such is the introduction to a truly insightful section of the book The Pragmatic Programmer.  The ideas presented in this section, like many great software engineering principles, expand beyond the realm of programming.

Programming in any existing language requires clarity of thought.  One significant component of that is the removal (or at least, verification of) assumptions.  This idea is equally applicable to any problem we might face in the "real world."  When trying to solve such a problem, assumptions can really be the enemy:

If the "box" is the boundary of constraints and conditions, then the trick is to find the box, which may be considerably larger than you think.

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you'll find your solution... 

It's not whether you think inside the box or outside the box.  The problem lies in finding the box - identifying the real constraints.

This really resonated with me.  When given a problem, we are almost never given the full set of real constraints.  Most constraints are assumed or imagined, leading us to believe we have a much smaller box.  This leads to potentially less effective (and certainly less innovative) solutions.

So what should we do?  The authors continue:

When faced with an intractable problem, enumerate all the possible avenues you have before you.  Don't dismiss anything, no matter how unusable or stupid it sounds.  

This isn't so ground-breaking.  It's basically the idea of "brainstorming" that we all learned in elementary school.  But the authors go a step further:

Now go through the list and explain why a certain path cannot be taken.  Are you sure?  Can you prove it?

This step is where I know I have failed in the past.  I can generate a list of fantastical ideas, but I know I have been too quick to prune some of the more outlandish ones.

I won't make that mistake again.
 

Wednesday, March 19, 2014

"He Who Can Do This Has the Whole World with Him"

Back in November of 2013, I posted about how to ask for a favor.  In a nutshell: make it so easy that people don't notice they're doing it.  This has clear implications for software design.

I just read that Cinemark went a step further: rewarding you for doing them a favor.

http://lifehacker.com/cinemark-rewards-you-for-turning-your-phone-off-during-1545581081

Now, I can't comment on the efficacy of this app, but I love the principle.  I'll again reference Dale Carnegie: "There is only one way under high heaven to get anybody to do anything... And that is by making the other person want to do it."  He further says: "So the only way on earth to influence other people is to talk about what they want and show them how to get it."

Let's think about the moviegoer with his phone on.  Sure, he may not want to disturb others in the cinema.  But when he gets a Tweet of a cat doing something funny (or Instagram buzzes with a picture of what his second cousin is having for breakfast) his personal desire suddenly trumps his concern for the rest of the audience.

Cinemark's tactic, then, is based on realizing that people care about their own desires much more than the desires of others.

Why has it been so hard to get people to behave in an environmentally-friendly way?  This same reason!  People care more about their personal inconvenience and/or expense than helping literally the rest of the planet by being green.

So what did Tesla do?  Did they market their cars as a way to help the environment?  No!  That would be appealing to the wrong desire.  They market their cars as high-performance status symbols.  If you go to teslamotors.com right now, you'll see that the biggest statement on the front page is "THE HIGHEST SAFETY RATING IN AMERICA."

In other words, they are showing you how you can benefit yourself.  They know that you really care about that more than the environment.

So whether we are building software or marketing a product, we must realize that the only way to get people to do something we want is to give them what will benefit them personally.