Three Windows Mobile developers, Mort, Elvis, and Einstein, are sitting at the lunch table when their project manager bursts into the room.

PM: "Guys, I have some good news and some bad news."

Mort: "Tell us the good news first!"

Elvis: "Wait! I need to grab my laptop and take copious notes."

Einstein: "I have a theory about what you are going to tell us."

PM: "Be quiet and listen. The good news is that we bought iPhones for all the software developers".

Mort: "iPhones? But the product only targets Smartphones!"

Elvis: "Cool! Where is the SDK?"

Einstein: "You should've waited for an updated iPhone that includes GPS!"

PM: "The bad news is your iPhone is also your severance package. We've just moved all product development work overseas."

One of my first evaluated public speaking events was a disaster.

In high school, my teacher filled a basket with index cards. Each card had a "topic" printed on it. One by one, we had to go to the front of the room and pick a random card from the basket. We then had 60 seconds to prepare a 5-minute presentation on the topic we selected. 

When it was my turn, I went to the front of the room and picked out a card. I looked, and my card said, "Break on through to the other side". I put the card in my pocket.

An abbreviated version of the next 60 seconds inside my head went something like this:

What does he expect from this? A motivational speech? I can't give a motivational speech! What are we suppose to break through? School? What's on the other side of school? This is terrible. I don't know what to talk about. I should say I'm going to the bathroom and pull the fire alarm.

Wait - this is a Door's song. Jack likes the Doors. I remember seeing another song called "Peace Frog". What a strange name for a song. "Peace Frog". Frogs eat flies.

Is my fly open? No. 

If my fly was open in front of class, Melanie Weigel would be laughing and telling the whole school. She's such a drama queen. One day I'm going to fill her locker with shaving cream – just to see the scene she creates.

Flys.

Frogs.

Frogs are green.

Kermit the frog is green.

I loved the Muppet show. Especially those two old guys sitting in the balcony, razzing on everyone. I wonder if the show is ..."

Ding!

With no escape in sight, I put on my bravest face and stood behind a little podium at the front of class. Having completely forgotten my original topic, I proceeded to ramble for 5 minutes about characters on the Muppet show. You can't go wrong talking about Muppets. Everyone loves Muppets!

I could tell by my teacher's expression he wasn't loving Muppets. He asked me what was printed on my card. When I pulled out my card and announced my topic, there was about 10 seconds of dead silence. Everyone was trying to figure out how I went from "Break on through to the other side" to a television show about hand puppets named Miss Piggy and Dr. Bunson Honeydew.

Grade: 2/10.

I've worked really hard over the years to get better, and stay on topic.

I respect faith, but doubt is what gets you an education. - Wilson Mizner

Everyone starting a new software development project needs to have some faith. You might have faith in a particular tool, or programming language, or development process, or all the above. I hope you also have faith in yourself, and your colleagues, too, because that kind of faith gives your project a greater chance to succeed than any faith based in methodologies or silicon. At least this is what I believe.

Blind faith can be bad. It's good to occasionally look around with an open mind to see what works for the rest of the world. If you think your choice of programming languages is the best, for instance, go search for criticisms and look at alternatives. You don't have to switch to a new language, and you just might come away with a better perspective on technology and learn a few new tricks.

At least once a year, go faithless for a day.

Back in the old days (just last year, in fact), the stock disk defragmenter in Windows looked something like this:

If you had no choice but to defragment a drive immediately, then at least you could entertain yourself by watching little green and red stripes bounce around inside the window. A quick glance could tell you if the defragmentation was nearing completion.

Along comes Vista, with a new defragmenter interface:

The defragmenter takes more of a Hollywood "don't call us - we'll call you" approach. I haven't found any red, green, and blue bars moving around to pass the time.

All I have left is hope.

I hope this finishes.

I hope this finishes soon.

You don't need a weatherman to know which way the wind blows – Bob Dylan, Subterranean Homesick Blues.

What direction does the wind blow in your software?

It's easy to feel the direction of the wind when standing outside, but software is subtle. One of the guiding rules in interface design is the Principle of Least Surprise (POLS). This principle states that developers should choose sensible defaults and implement behaviors that don't surprise or astonish users. We can use the rule as a guide when implementing a user interface, or building an API / library / framework.

POLS is more of a policy than a rule, though, because it's impossible to enforce a rule inside the gray zone of how users think. Typically, you have to pick what sort of user your interface targets, and try to give that class of users the least surprising behavior. 

For example, Subversion applied POLS like so:

We should behave as similarly to CVS as possible -- the Principle
Of Least Surprise. This is really important, and was not given
enough attention in the previous discussion imho. There's no
point being gratuitously different if we can be an intuitive
superset instead.

Of course, your approach won't make every user happy. You'll still need to make trade offs. In "10 Things I Hate About Ruby", Elliote Rusty Harold (author of Java I/O) is surprised by some of the conventions in the king of POLS:

Naturally you think the constructor would be defined in a method called new, right? Or just maybe a method called Car like in Java? But no, instead it has to be called initialize like this:

It's impossible to keep every user unsurprised, but it is possible to surprise a large percentage of your users. I tell people all the time that trying to disable the back button in a browser window isn't 100% possible and will astonish the users. Many users like the back button. I like the back button. Still, developers insist on trying to disable the back button. This tells me the software wants me to work under a different set of rules than I expect. When the back button disappears, I know an ill wind is blowing.

I want to ask you a question about ethics.

Let's pretend you've been working under contract to write a handful of components for some larger project. Nobody told you what the larger project really is, but the contract pays well and you've been given all the information you need to finish your work.

About the time you've reached the halfway point in your work, you uncover the goal of the larger project. The project is an application that will email thousands and thousands of phishy messages and collect information from users through a website. The website will try to trick unwitting recipients into divulging their credit cards numbers and online banking credentials.

At this point, you have to make a choice. Let keep this hypothetical questions simple, and restrict you to one of two choices:

1. Finish your work. Take the money.
2. Breach the contract. Cease work immediately.

Do you consider #1 unethical? What about #2?

Let's throw in one more option:

     3. Keep working on the project, but inject some monkey business.

What if, for #3, you delivered some code like this:

Or this:

Or this:

Those code snippets give the software problems that are hard to track down. Is #3 being unethical, or being a vigilante?

Note: I've never been in such a situation - I'm just taking a poll.

Once you've worked in as many software startups as I have, then you'll know there can be a Dilbertesque relationship between engineering and sales/marketing. If you use a microscope to examine the brain of an engineer, and the brain of a marketing person, then you'll find obvious biological differences - the brains are wired differently. The two brain types tend to blurt out dissimilar and conflicting ideas when sitting in front of potential customers, and thus we have plenty of stories to laugh about after the pain subsides.

When you return to the office from a "sales" meeting, all of your colleagues want to know "how it went". Since we don't have an empirical measure for these things, it takes a lot of explaining to describe "how it went".

Ship captains faced a similar problem describing wind intensity until Sir Francis Beaufort devised the Beaufort Scale in 1805. Let's say you are a captain returning to the pub after a rough day at sea. You meet another captain, who wants to know what the conditions are like. You could say, "There were moderately high waves with breaking crests forming spindrift – and streaks of foam, too." Alternatively, you could say, "Today was a total 8 on the Beaufort scale." The latter answer is shorter and helps you reach the pub in less time.

I've devised the "Sales Force" scale in the interest of saving time. Sales Force measures the intensity of the reality distortion field in a sales / engineering / customer meeting.

Sales Force Level 1
Description: Calm.
Conditions: Sales presented all the material prepared by engineering without alteration.

Sales Force Level 2
Description: Gentle.
Conditions: Sales presented some technical inaccuracies that nobody else noticed. For instance, "our database is written entirely in Microsoft's awesome C# language".

Sales Force Level 3
Description: Moderate.
Conditions: Sales made some statements you wouldn't agree with. For instance: "our application is totally using AJAX for an awesome user experience", when in fact only four web pages in 100 use AJAX.

Sales Force Level 4
Description: Squirming in seat.
Conditions: Sales is making some bold claims for scenarios you've never tested. For instance: "our software can scale to 10 million users without breaking a sweat".

Sales Force Level 5
Description: It's getting ugly.
Conditions: The customer just asked for a feature of such magnitude that only quantum computers cooled by liquid nitrogen could do the job. Sales replied: "yes, we have that in the plans for next quarter".

Sales Force Level 6
Description: Total WTF.
Conditions: Sales described some feature of the software you've never heard about. Perhaps this was something they dreamed, but you know they'll expect you to build it. Quickly.

Sales Force Level 7
Description: Apocalypse Now!
Conditions: Sales presented screen shots of a "shipping application" where the screen shots were actually UI sketches built in Photoshop by a tattooed designer named Pablo who never came back to work after last year's Burning Man festival.

Next time someone asks how the meeting went, you can just say, "Dude, it was a total Sales Force Level 7 meeting - I'm updating my resume". You'll get to the job boards even faster.