Negotiation starts from confidence

It seems obvious when you think about it, but I don’t hear it said very often: The first step toward getting what you want is knowing what you want. You have to do more than recognize what you want, you have to be confident in it.

Here’s an example from my college days: I worked at a bar for a couple of years. On weekends, we’d have someone at the door checking ID. There were plenty of people who tried to talk their way in without any.

One night the regular doorman was late, and I covered for him. The first girl who showed up without ID smiled, batted her eyelashes and asked “pretty please?” I said something like, “Gee, I really wish I could, but rules are rules, etc.” She argued, I refused, she got mad … I’d like to chalk my behavior up to my youth and her smile, but the bottom line is I didn’t project confidence in what I wanted.

The next girl who showed up without ID (for some reason guys never tried this with me, I don’t know why) I just told her I needed ID or she couldn’t get in, sorry. She threw a quick pout, then left to find someplace else she could get into.

As I thought about this later I realized the first girl wasn’t mad because she wasn’t allowed in. She was mad because I gave the impression I might be open to negotiation but I wasn’t.

Moral of the story: Know which of your goals are negotiable and which ones aren’t. Never give the impression that one of the former might be one of the latter. Reasonable people can respect an honest difference of opinion, but will read indecisiveness as an opportunity to negotiate.

Update: I found another way of putting this, on Scott Berkun‘s site where he explains why things suck:

It’s the things that tease us, making us think they’ll satisfy us but then failing, that hurt the most.

He was pointing out that people don’t complain about things they don’t care about, but it works really well to explain what happened to me when I was working at the bar.

Here’s a crazy thought

Corel should sue people who use Photoshop without paying.

Huh?

Think about it. Graphics professionals pay for Photoshop. Lots more people do some graphics, but not enough to be worth $650. But many of those people possibly would agree that their use is worth $80.

So there are probably people using cracked copies of Photoshop who, if they didn’t have the crack, would instead have bought Paint Shop Pro.

It seems reasonable that if we’re going to report losses to “piracy” in terms of lost sales, we should be counting the potential sales that are really lost.

Writing a test approach

If this is the first time someone has asked you to produce one, it’s kind of an odd exercise.

First, recognize that you have some pretty significant prerequisites, and second that you have to consider multiple audiences. But what it all comes down to is making sure that the application does what it’s supposed to do.

The prerequisite comes from needing a good definition of “what it’s supposed to do.” I wish this were as easy as it sounds. Look at how much is written about whether/how to write specifications to see what you’re up against.

Once you have a good spec, you have two questions to answer. It’s really the same question answered for two audiences, but the answers can be pretty different: How do you ensure that it does the right thing; and how do you demonstrate to your client that it does the right thing?

Answering the first question will involve unit testing, regression testing (for upgrades), creation and execution of test scripts, etc. It’s possible a large part of the execution will actually be done by the developers.

Answering the second question — satisfying the client — requires that you talk in terms of: user interaction, use cases, end-to-end scenarios, scalability/performance/load testing, support and training needs, etc.

Imagine you are presenting a sales pitch to a client, and you need to describe how you will demonstrate the value and correctness of your application. Write a narrative proposal, eg:

Working with end users and subject matter experts (name names if possible), we will define use cases that describe the expected functionality of the application. This process should take X hours of the users’ time over the course of Y days.

These use cases will be executed and verified by someone, using volume of data extracted from source. Developers will also create automated scripts to be executed on toolname, simulating how_many concurrent users executing how_many transactions per second for how_long.

You’re not trying to actually write the test scripts yet. Start out with the higher-level description of what types of testing you expect to do, and who is responsible for writing and executing each type. Theoretically you may not know the performance figures in that second paragraph, but I find it’s better to put some numbers in front of the stakeholders and let them disagree.

Can someone give me the name of a good buggy whip maker?

No really, I want to talk to one. There should be several in every large town, just like there used to be. Because it would be immoral to deprive them of their “right” to make money in the way that they want to.

“But that’s absurd,” you say, if you’ve never heard the argument before. “You’d have to outlaw cars to protect the buggy whip manufacturing business.” Yes, and that’s exactly what the buggy whip makers tried to do: ban the car.

Copyright does the exact same thing buggy whip makers tried to do: it protects a specific business model. The “right to control copying” exists to encourage people to go into the business of creating new works.

We, as a society, benefit from having new works. We have agreed to grant creators of those works a temporary monopoly on reproducing and selling those works. If the specific method that we’re using to encourage creation actually serves to restrict creation, our method needs to change.

Everyone who thinks the RIAA is responsible for increasing the net creative output of the world, raise your hand … Everyone who thinks the MPAA is the creative force behind independent film, raise your hand …

Copyright law was a specific solution to a specific problem. It doesn’t codify some inherent human right. If the “solution” has been pushed too far in one direction, which I believe it has, it’s time to re-think the balance. Or maybe come up with some new way to encourage creation of easily-copied works.

Apples and Oranges …

… are actually pretty damn similar.

How did “like comparing apples and oranges” get to be our standard phrase for indicating that two things are so different as to resist comparison? They’re both fruit, typically about the size of a baseball, have a skin and seeds, are mostly water. There are more similarities than differences.

I assumed there was some history to this phrase, some context where it made sense. The only thing I can find is a one reference suggesting, “that the phrase appeared as apples and oysters in John Ray’s proverb collection of 1670.” Okay, that makes a bit more sense. Or at least it works better for what people mean when they say it.

But I suspect it’s more like the phrase, “You can’t judge a book by its cover.” Really? Put a Unix textbook next to a Harlequin romance and I’ll bet I can tell you a whole lot about it. That phrase originated in a time when all books were printed with blank bindings, and covers could be applied by the seller or the customer. So back then no, you really couldn’t tell a book by its cover.

No one cares about “average”

No one wants to be average. We just want to treat everyone else like they are. That’s why we generalize, form stereotypes. It leads to goth and emo, as kids try to be unique and different from average people … but in exactly the same way as everyone else in their preferred group. (Oops, was that cynical?)

It also leads to being pretty spectacularly wrong in your conclusions, even when you’re completely right in your premises. Take for instance what Joel Spolsky had to say about OSS development:

Development [on OSS projects] is much more likely to be geographically dispersed, which results in a radically different quality of team communication. It’s rare in the open source world to have a face to face conversation around a whiteboard drawing boxes and arrows, so the kind of design decisions which benefit from drawing boxes and arrows are usually decided poorly on such projects.

His premises are correct: development is often dispersed; design can suffer. His conclusion, that OSS projects usually just clone existing (closed source) software is not technically wrong, but is irrelevant for the same reason traditional media is wrong when they discount blogs as “real writing”: The average doesn’t matter. If the best blog — or the best OSS product — is better than the leading commercial media or closed software, it will gain market share.

As Paul Graham says:

Those in the print media who dismiss the writing online because of its low average quality are missing an important point: no one reads the average blog. In the old world of channels, it meant something to talk about average quality, because that’s what you were getting whether you liked it or not. But now you can read any writer you want. So the average quality of writing online isn’t what the print media are competing against. They’re competing against the best writing online. And, like Microsoft, they’re losing.

The “average” application on SourceForge may be derivative and just plain bad, but you don’t install averages. You install applications. I don’t use an “average browser”, I use Firefox.

This holds true for games, too. As a Slashdot poster says of open-sourcing a game:

we will see millions of variations of modifications that will be incompatible with each other and that will bring down the quality of the game. Some will be much worse than the original, probably few will add high-quality content, but some may become very good indeed.

Software, writing, games, in fact all digital media, tend toward a winner-take-all outcome. In the age of infinitely-reproducible goods, it doesn’t matter what process yields the best average outcome. What matters is what process yields the single best outcome.