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.
Sunday, October 19, 2014
Tuesday, September 16, 2014
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.
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.
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.
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.
Subscribe to:
Posts (Atom)