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.

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.

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."

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.
 

"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.