GAAP and knowledge-intensive/high-risk companies

Dave Long (
Wed, 12 May 1999 11:00:13 -0700

> > But a crash need not be a crash - think of a swarm of bees. Suddenly they
> > all disrupt themselves and move to another hive. So what?

So what, unless the rents from one of the hives accrue to you.

> >
"Why Generally Accepted Accounting Principles generally do an unacceptable job
of accounting for the principal activities of knowledge-intensive companies."

A nice article (if only the "quantum" analogy didn't make me cringe) but
although it does a nice job of "How" GAAP do a poor one, it fails to explain

A "knowledge-intensive" company is for these purposes, no different than a
"highly-speculative" company. GAAP says that one should place conservative
valuations on assets and activities; in these cases that means that something
which has a reasonable probability of being worthless (R&D, training, brand
building, most software, etc.) should be accounted for on that basis, and
hence are expenses.

When the spread of likely outcomes is narrow, accounting can do a good job of
capturing the resulting distributions. Until it uses a more complex
representation, however, it can't do a good job of capturing the distributions
resulting from highly variable outcomes.

One might argue that GAAP do a very good job for a particular audience:
bondholders are interested in knowing that a business is capable of meeting
its debt obligations for all reasonable outcomes. Because shareholders are
more interested in either modal or median outcomes, it isn't surprising that
their information interests would diverge.


from the article:
> Working closely together, they strive to distinguish between, as
> Smith puts it, "perceptual risks and real risks, or between a pause
> and a crash." The key to knowing the difference: knowing the
> management. Smith says: "We form an extraordinary level of
> intimacy with management. We have to. The quality of the
> management team that the technology is able to attract tells us a lot
> about the quality of the technology--more than anything else does."

We may not know about technology, but we certainly have opinions about
managers, so let's look for our lost keys under the streetlight.

Someone ought to hire financial engineers, and put them on router teams.
Imagine what they could do for TCP flows: "no, of course we haven't had any
acks just yet, but we're going to have a whole bunch real soon now (after all,
there are some quality algorithms running here), so send more packets"