Tips from Leo Reilly in How to Outnegotiate Anyone (Even a Car Dealer!).

• Be patient. If you insist on having something today, know what you want and be prepared to pay for it.
• Never disclose your deadline.
• Cultivate a positive relationship with the other party.
• Don’t make the other side look stupid (for a prolonged period of time).
• The best negotiators talk only 40% of the time.
• The most intimidating thing you can do to someone trying to intimidate you is to not be intimidated.
• Never be the one to make the first offer.

The most critical aspect of negotiation is the opening offer. Four opening gambits are possible:

1. Lowballing. Offering substantially less to create psychological downward pressure on the price.
2. “Up against the wall.” Forcing the other side to make more concessions than you do.
3. Anchoring. Having both sides make equal concessions.
4. “The Kiss.” Like anchoring, except allowing the other side to take one final (often minor) concession.

If you want to find out what Leo says about how to buy a car, in 5 minutes, below dealer cost, you’ll have to pick up the book though. :-) -m

Holding steady at 1280 x 854 but due for an upgrade soon.

Seriously, if you find yourself setting various goals just because something on the calendar changed, you probably don’t have the long-term motivation needed to see it through, which is why so many new years’ resolutions lie in broken heaps by mid February. If you think something is worth doing (like this for example), then forget the calendar and do it.

-m

This blog page at the W3C discusses the TAG finding that a data format specification SHOULD provide for version information, specifically reconsidering that suggestion. As a few data points, XML 1.1 (with explicit version identifiers) is something of a non-starter, while Atom (without explicit version identifiers) is doing OK so far–though a significant revision to the core hasn’t happened and perhaps never will.

In a chat with Dave Orchard at XML 2007, I suggested that the evolution of browser User-Agent strings might be a useful model, since it developed in response to the actual kinds of problems that versioning needs to solve.

Indeed, the idea seemed familiar in my mind. In fact, I posted it here, in Feb 2004. The remainder of this posting republishes it with minor edits for clarity:

‘Standard practice’ of x.y.z versioning, where x is major, y is minor, and z is sub-minor (often build number) is not best practice. If you look at how systems actually evolve over time, a more ‘organic’ approach is needed.

For example, look at how browser user agent strings have evolved. Take this, for example:

Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows 98) Opera 7.02 [en]

Wow, if detection code is looking for a substring of “Mozilla” or “Mozilla/4″ or “Mozilla/4.0″, or “MSIE” or “MSIE 6″ or “MSIE 6.0″ or “Opera” or “Opera 7″ or “Opera 7.0″ or “Opera 7.0.2″ it will hit. If you look at the kind of code to determine what version of Windows is running, or the exact make and model of processor, you will see a similar pattern.

Since this is the way of nature, don’t fight it with artificial, fixed-length major.minor versioning. Embrace organically growing versions.

The first version of anything should be “1.” including the dot. (letters will work in practice too) All sample code, etc. that checks versions must stop at the first dot character; anything beyond that is on a ‘needs-to-know’ basis. A check-this-version API would be extremely useful, though a basic string compare SHOULD work.

Then, whenever revisions come out, the designers need to decide if the revision is compatible or not. A completely incompatible release would then be “2.”. However, a compatible release would be “1.1.”. All version checking code would continue to look only up to the first dot, unless it has a specific reason to need more details. Then it can go up to the 2nd dot, no more.

Now, even code that is expecting version “1.1.” will work fine with “1.1.1.” or 1.1.86.” or “1.1.2.1.42.1.536.”.

Every new release needs to decide (and explicitly encode in the version string) how compatible it is with the entire tree of earlier versions.

Now, as long as compatible revisions keep coming out, the version string gets longer and longer. This is the key benefit, and why fixed-field version numbers are so inflexible. (and why you get silly things like Samba reporting itself as “Windows 4.9″).

One possible enhancement, purely to make version numbers look more like what folks are used to, is to allow a superfluous zero at the end. This the first version is 1.0, followed by 1.1.0, 1.1.1.0, (this next one made an incompatible change) 1.2.0, and so on.

So if a document needs to self-version at all, perhaps a scheme like this should be used? -m

Many things in life are simpler when you only need to be within 5%:

• Pi is pretty much 3
• Water weighs pretty much 8 pounds a gallon
• A quart is pretty much a liter (and a gallon, 4 liters)
• A year has pretty much 360 days, and pretty much 31 million seconds
• The speed of light is pretty much 300,000 km/s, which is pretty much one foot/nanosecond

Of course, there’s even more things that get more convenient when you have 10% or 20% to work with… -m

My Copious Free Time(tm) has been filled lately by two different evaluation projects. One is the 2nd Annual Writing Show Best First Chapter of a Novel Contest, for which the first round of judging is just winding up. The main benefit for contest entrants is that every submission gets a professional critique of at least 750 words. But additionally, each submisison gets a score on a 50-point scale, based on:

• 10 points for Story. Is it a compelling read with a great hook? Are we engaged?
• 10 points for Style. Is the writing smooth and tight, without awkward constructions, extraneous verbiage, and redundancies?
• 10 points for Dialog. Is the dialog natural and does it move the story along?
• 10 points for Character. Are the characters interesting? Do we care about them?
• 10 points for Mechanics. Are grammar, spelling, and punctuation correct?

I’m also attending some classes aiming toward becoming a Certified Beer Judge (details on Meadblog). This isn’t as fun as it sounds. (Well, OK, maybe it is…). The idea is to build up better sensory perception so that my personal brewing and cooking projects can benefit. But the upcoming test is 70% written essay questions like “Identify three distinctly different top-fermenting beer styles with a starting gravity of 1.070 or higher, and describe the similarities and differences between the styles”. 30% of the test is based on actual tasting and filling out a tasting sheet. Of interest, the scoring here is also based on a 50-point scale:

• 12 points for Aroma.
• 3 points for Appearance.
• 20 points for Taste.
• 5 points for Mouthfeel.
• 10 points for Overall Impression.

The interesting part is that there’s similarities between the two tasks. For both, I need to work off of physical paper, not in my head on on a computer screen. For both, I first “skim”, building an overall impression, then dig down into individual categories to assign a score for each one. Then I step back and look at my numbers, and check whether everything makes sense and accurately records my impressions. When I’m satisfied, I add everything up and am done.

Most day-to-day problems aren’t so well structured or normalized, but nonetheless, I find myself tackling all kinds of problems with a similar approach. There you have it. Writing and drinking beer make you a better person. :) -m

If it’s been quiet on this front it’s because I’ve been engrossed in my continuing education. Andy Oram sent me a copy of Beautiful Code, a thoroughly enjoyable work from O’Reilly. If you like stretching your brain by reading code-intense essays from top-tier coders, I recommend this volume. In particular, I’m been digging into Douglas Crockford’s Top Down Operator Precedence chapter.

Other than that, some interesting BJCP classes, but I’m keeping that non-tech stuff over on meadblog. -m

my new publishing technique is unstoppable - but why limit to blog posts?

GET Introspection URI
   scan the list of workspaces for the collection you want to post to
GET to Collection URI
   read the nice [atom] feed 
POST to the collection URI
   push an item formatted as [a nice atom entry]
GET or HEAD to item URI
   grab the item
PUT or DELETE to item URI
   change or delete the  item

-m

A little bit back, Cringely had a brilliant column about billable events and the last mile. Everything the telcos (and others) do these days is primarily aimed at creating billable events. This includes the net neutrality debates.
In fact, at&t is so skilled at revenuing, they can generate billable events out of nothing at all. Here’s a short quote from a recent phone bill:

The FUSF pass through fee charged to some customers has been reduced and credit may be due. Due to the large volume, any applicable credits generated in 2005 or 2006 may appear on a future bill. The average one-time credit will be less than $1.50.

No problem manufacturing extra charges in “large volume” since at least last year, but when it comes to refunds (and very partial refunds from the look of it), it sure takes a long time.

Speaking of long times, another thing the telcos aren’t very quick about is transferring service. Took them 11 days to establish service at my new address, with a $37 billable event to boot. But I’m back online now. If you’ve sent email in the last 2 weeks and haven’t seen a response, it might be a good idea to resend. -m

About a year ago, on this blog I started a series called “Patternalia”, examining various patterns in technology and life in the style of a popular Christopher Alexander series. Over the coming weeks and months, I’m going to revive the series, first of all by getting the old entries into WordPress. Everything will be under the patternalia tag for safe keeping.

Now a cynic might think this is a cheap way to keep my blog rolling during a particularly busy point in my career. But even cynics follow patterns. :) -m