February 2007 Archives

Sales culture

The culture of sales organizations and salespeople is a fascinating thing. I started getting into sales around 10 years ago (the I Hate Selling book was useful to me), but only recently have I witnessed sales management culture, the relentless pressure, and the personalities.

Sales people have such a unique role and set of responsibilities that few can handle. Examples include:

  • accountability to make committed sales projections,
  • pressure from customers,
  • dealing with support for products that don't always work,
  • choosing pre-sales engineers that don't always fit the situation,
  • dealing with screaming, crying, scheming, and outbursts of emotions both inside and outside the company,
  • handling pipeline pressure from management (who typically manage pipelines statistically via spreadsheet, even though sales is a very empirical, situational process),
  • and , in the end -- deal closing, which involves fighting with finance and legal to insist that you're not trying to bring down your own company or the customer's company, you really just want to sell some software and/or services.

There's also three fabulous movies to see to understand the culture. Wall Street, Glengarry Glen Ross, and more recently, Boiler Room. They're dramaticised into moral fables about greed & corruption, but the pressures and personalities of different types of sales superstars and managers are spot on.

Some wonder if sales is even necessary -- if marketing can make products "sell themselves", or if the world will become dispassionate logical evaluators of purchases, or that legal & financial negotiations will become manageable by small companies. Somehow, I doubt it.

Http Multiparts and the case of the missing CRLF

A cautionary tale for those who believe they have the grand interoperability mojo.

There once was a big customer, an XML appliance and a web services stack. The XML appliance implemented HTTP 1.1, aka RFC 2616 and MIME, aka RFC 2046 as most expect one to. They also implemented SOAP with Attachments and the WS-I Attachments Profile, as all good enterprisey people should.

But there was something odd about how many carriage return + line feeds (CRLF) to include between the last HTTP header and the start of a multipart/* entity body. The appliance sent three CRLFs, and required three, and rejected that which did not have three. The web services stack sent two and expected two, but tolerated more. Sending multipart messages to the appliance broke.

Big customer complained. XML appliance didn't budge. Web services stack, like all good software groups, believed they were in error, and fixed the issue. All was well for over a year...

...Until application server A came onto the scene. It, strangely, exhibited the same problem as the web services stack did many months prior. Big customer complained: You are out of compliance! We require compliance! You are trying to lock us in! The big customer & application server vendor both beat their heads together, thinking that perhaps the RFCs were inconsistent, or ambiguous. Eventually big customer figured that compliance is irrelevant (though, naturally, after the non-compliance tongue-lashing), interoperability is more important, whatever the fix.

In the end, of course, the RFCs, one of which dates back to 1996, are not inconsistent. It's that implementers sometimes don't read carefully.

The misleading part is in RFC 2046, Section 5.1.1:

"NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). "
But when one reads the BNF, we notice this isn't always true:
     dash-boundary := "--" boundary
                      ; boundary taken from the value of
                      ; boundary parameter of the
                      ; Content-Type field.

     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]

     encapsulation := delimiter transport-padding
                      CRLF body-part

     delimiter := CRLF dash-boundary
Wherein we see that the first MIME multipart dash-boundary doesn't include a CRLF. That CRLF is rolled into the preamble as optional. Unfortunately, it doesn't help matters when the WS-I Attachments Profile, Section 3.12, R2936 says:
"Certain implementations have been shown to produce messages in which the MIME encapsulation boundary string is not preceded with a CRLF (carriage-return line-feed). This creates problems for implementations which correctly expect that the encapsulation boundary string is preceded by a CRLF.... RFC2046 section 5.5.1 clearly requires that all encapsulation boundaries must be preceded with a CRLF (carriage-return line-feed)."
Yikes. I've sent an email feedback to the WS-I organization indicating that this seems to be a misstatement.

Informal testing (ymmv) indicates spotty compliance of how many CRLFs are between the last HTTP header and the first MIME boundary:

  • Application Server A inserts 2 CR/LF, expects at least 2
  • Application Server B inserts 3 CR/LFs, expects at least 2
  • Application Server C inserts 2 CR/LFs, expects at least 2
  • Web Services Library A inserts 3 CR/LFs, expects at least 2
  • Web Services Library B inserts 2 CR/LFs, expects at least 2
  • XML Appliance inserts 3 CR/LFs, requires at least 3
The morals of this story:
  1. do not just trust specification text -- read the formal grammar
  2. "compliance" doesn't necessarily mean interoperability
  3. software seems more forgiving than hardware

oscar! oscar!

I'm an Oscar nut. I think I've watched every one of them since I was 2 years old. I find they're long and can drag, but otherwise are a fabulous Sunday night. As fun as watching the Superbowl. Yep, I guess I'm odd.

Marty Scorcese gets his well-deserved Oscar. I think The Departed was by far the best movie of the year, followed by The Queen. I think Little Miss Sunshine is good, but not that good. Pan's Labyrinth had a better screenplay. But at least Pan's got three well-deserved golden dudes.

I liked Ellen. She started off nervous, but seemed to improve, with only a few bad jokes. The Jack Black, Will Farrell & John C Reilly skit was hilarious, as were Steve Carrell & Greg Kinnear, and even Jerry Seinfeld was ok.

The Oscars this year seemed goofier, quirkier, more self-aware that all the glam and pomp is just a front. Which does seem a bit like Ellen's personality. It was a long night, dragged at times, but felt a bit livelier than last year (though I enjoyed Jon Stewart).

JetBlue

Guess what infrastructure JetBlue runs? I recall reading about their Microsoft-only environment back in 2001, and thinking "this could eventually bite them hard". Not that it's the reason for the operations meltdown -- that's not public info. I also believe that Microsoft's infrastructure can scale quite well.

The trouble is, in my experience, there's a false belief in some IT managers that Microsoft's software infrastructure is somehow a magical elixir to keep infrastructure costs low. That's tripe. There is no panacea in picking one vendor over another in terms of keeping infrastructure costs down in the face of increasing demand.

Maybe when JetBlue built its infrastructure out, Microsoft's approach really was the best way to keep costs low from a combination of developer productivity, hardware + software costs, maintenance & support costs, training costs, etc. But apparently they didn't track their scalability assumptions to deal with problem scenarios, like the recent Valentine's Day storms.

Broad, sweeping generalization time: there are two types of managers - those that want to sign a check and not think about their problem, and those that want to think their way through a problem. The latter is politically riskier, but the former is much riskier in reality. It's not that Microsoft's stuff can't scale, it's that management doesn't invest in it relative to increasing demand, because they signed a check and "it's supposed to work" like all elixirs should! The same could be said for large IT outsourcing or offshoring deals, with questionable results. (I could have an entire post about management-by-spreadsheet now, but I'll stop...)

The question is about where the "straight and narrow path" of your chosen infrastructure hits the scalability wall. At some point, building an infrastructure on a shoestring (and without systems architects that have a performance specialist background) is going to break your (and your vendor's) default scalability assumptions.

You need to actually know *what* scalability your hardware and software combination is capable of and not just blindly follow the trodden path of PHP docs, MSDN, IBM developerWorks, or BEA's eDocs. As Neil Gunther would say, your team needs to know and agree on what part of the scalability elephant they're feeling.

music trends

As much as difficult political situations suck, it certainly does (eventually) generate a lot of good music. Many underground styles are becoming quite mainstream. Drone doom, Black metal, Glitch Industrial, etc. And even old stalwarts are making a solid comeback.

Chicago Tribune: Black Metal Rises from the Shadows. Good quotes from Abbath. His band, -- I -- has released on of the best quality and most accessible black/thrash metal albums of 2006.


Sunn 0))) + Boris Collaboration, "Altar". Though it's not representative of the droney, mostly instrumental, album, it contains a gorgeous and accessible track worth hearing repeatedly. Also on iTunes


Skinny Puppy's Mythmaker, which some are calling their most accessible and relevant album in 13+ years. I AM THE UNDISPUTED LIE. OH YEAH.


Coming soon, the new Nine Inch Nails: Year Zero. Complete with viral marketing campaign. My Violent Heart is a leaked track.


Dimmu Borgir - In Sorte Diaboli. The reigning kings of popular black metal, with their first major release in 4 years. In Toronto on April 22nd!


Apple is charging $1.99 to activate the 802.11n support in select products, a feature that was left dormant to date.

I've been seeing lots of confusion about how the generally accepted accounting principles led Apple to charge for this, so I thought I'd give a few words on this matter. I'm not an accountant or a lawyer, but based my experience working for a software vendor, it's absolutely true.

Here's my layman's explanation.

Firstly, when a company sets accounting rules in place, it's mostly about setting up money buckets that are broken out for reporting to management and investors. Examples of buckets at Apple include: Macintosh, iPod, Peripherals, Software, etc. One has to be consistent in counting these sales, or else a company can slush money from one bucket to another if a product line isn't doing very well.

Secondly, because of the blurred lines between what is a software product and a service, and plenty of accounting shenanigans over the years blurring the two, there are very strict rules about when a public software company can "recognize" product revenue.. In the past, if a company that sold hardware, services, and software, was having a bad quarter, they'd sometimes sell a combination of services and software and be very liberal in its accounting (for example, discounting services to $0 and allocating the sale to license revenue). Or, alternatively, they'd discount software to $0 and accrue the balance to hardware sales.

Now, vendors are required to document "Vendor Specific Objective Evidence" (VSOE) for products that have multiple deliverables, which basically is a puffy term for "standardized prices". This way, if a software company like Microsoft, BEA, or Oracle were to also sell professional services, they must sell those services at or above the VSOE hourly rate (subject to variations).

Here's what may have happened: Mac OS X has many bundled features, and their accountants broke out the features by VSOE. And, it seems that device drivers have a deemed value of $1.99. Apple can't give it away the 802.11n enabler for free because they can't recognize the revenue on their hardware until all the pieces are delivered! They have to break out the 802.11n into a separate product that's not tied to the original product, and sell it at its VSOE-documented fair value to demonstrate this wasn't really just a hidden software discount intended to inflate hardware revenues.

The above may all be false, and again, I'm not an accountant, nor do I have inside Apple information. If you're interested, the standards are SAB 104 and SOP 97-2, which Apple claims it conforms to in its SEC filings.

Update 2/13/2007: A colleague at BEA, Tim Joransen, suggests that Apple likely picked $1.99 for just this case and it has nothing to do with VSOE, it's just a case of avoiding deferred revenue & a restatement.

"The equivalent for would be to try and recognize revenue for a product feature that isn't yet shipping. Say we are selling Product X. We are shipping 2.6, but the customer really wants a feature that we plan for 3.0. If we in any way promise the feature for 3.0 and tie it to the deal, then we cannot recognize the revenue until 3.0 ships.

If Apple had not monetized it some way, then someone may have made a case that the product wasn't done and the revenue should have been deferred...leading to a huge restatement."

About this Archive

This page is an archive of entries from February 2007 listed from newest to oldest.

January 2007 is the previous archive.

March 2007 is the next archive.

Find recent content on the main index or look in the archives to find all content.

About Me
(C) 2003-2010 Stuart Charlton

Blogroll on Bloglines

Disclaimer: All opinions expressed in this blog are my own, and are not necessarily shared by my employer or any other organization I am affiliated with.