No more need to settle for outlines and a sample chapter any longer. The earliest form of my book is now available, dear reader. I'm looking for intelligent critiques, observations, hints.
click.
I hope to tighten it up a bit before entering it into the B&N self-publishing software. Once it's there, the goal is to use it as an ad for something longer and more treatise-like.
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
11 August 2011
28 November 2010
Reality is fractal
Mandelbrot was right. Reality is fractal. Just when you think you've discovered s straight line from A to B, you zoom in a bit and discover the zig-zags and the swirls.
Then you think, aha! within those swirls I've discovered a lower-level A and B, and between these two, anyway, there is a simple straight line. But when you make another zoom, you find it isn't so.
This truth pressed itself upon me recently when, for the sake of a quick paycheck, I agree to write a brief essay on "Accounting for Software Licenses." Can't be too complicated, right? So ... how does one account for software licenses?
Turns out there are swirls. First, do we want to talk about the accounting of the leesor or the lessee? From the point of view of the lessee, the payments it has to make on a regular basis (yearly? quarterly?) are treated, one might naturally suspect, as a liability on its balance sheet.
But maybe not. Is this a "capital lease" or an "operating lease"? If the former, then in general the lease is a liability for the borrower, and an asset for the lender. If it is an operating lease, though, it can be kept off-balance sheet which (many biz management types seem to think) is re-assuring to actual and potential investors. Are they right? Is it really re-assuring, or does the rational expectations theory rightly presume that the market sees through mere formalities?
Never mind all those squiggles and squirrels! What about the lessor's POV? Can't we at least achieve some clarity, some sort of straight line, there? No. Have I mentioned that reality is fractal?
In general, how a lessor treats a productive asset that it has lent out for the use of another will depend on whether the asset is classified as "direct financing" or as a "multiple-element arrangement." (There is a grey zone in between those two possibilities, and further swirls, but for my brief essay I ignored that zone.)
If a financing company buys software for me and lends it to me, and if that is the only thing it does -- if it doesn't promise any upgrades or trouble-shooting services, and it doesn't deliver same -- if in the words of one authority the lessor "has no involvement with the software that is inconsistent with being a lender" -- in that case, the lease is a loan, and my lease payments are a matter of paying off that loan. The accounting proceeds accordingly, with a "Lease Receivable" item on the vendor/lendor's balance sheet.
But if it does promise and deliver upgrades and the like, then this lease contract is a "mutliple-element arrangement," more akin to a sale than to a loan. It becomes necessary to distinguish and value the different elements of the deal. This is true, too, of the loan of tangible equipment (you might lease me a backhoe with servicing promises). But distinguishing the separate elements in a software contract is apparently especially tricky, and auditors will require vendor-specific objective evidence (VSOE) of the value of the different components.
Zoom in further, and try to grapple with what VSOE means, and what are the consequences when VSOE can't be produced, and you get yet further Mandelbrotian swirls within swirls.
And there is the additional complication that software often comes embedded in hardware -- the "appliance" model. So the question of distinguishing among the elements of the arrangement may include the complexity of distinguishing the valuing of the dance and the dancer.
Then you think, aha! within those swirls I've discovered a lower-level A and B, and between these two, anyway, there is a simple straight line. But when you make another zoom, you find it isn't so.
This truth pressed itself upon me recently when, for the sake of a quick paycheck, I agree to write a brief essay on "Accounting for Software Licenses." Can't be too complicated, right? So ... how does one account for software licenses?
Turns out there are swirls. First, do we want to talk about the accounting of the leesor or the lessee? From the point of view of the lessee, the payments it has to make on a regular basis (yearly? quarterly?) are treated, one might naturally suspect, as a liability on its balance sheet.
But maybe not. Is this a "capital lease" or an "operating lease"? If the former, then in general the lease is a liability for the borrower, and an asset for the lender. If it is an operating lease, though, it can be kept off-balance sheet which (many biz management types seem to think) is re-assuring to actual and potential investors. Are they right? Is it really re-assuring, or does the rational expectations theory rightly presume that the market sees through mere formalities?
Never mind all those squiggles and squirrels! What about the lessor's POV? Can't we at least achieve some clarity, some sort of straight line, there? No. Have I mentioned that reality is fractal?
In general, how a lessor treats a productive asset that it has lent out for the use of another will depend on whether the asset is classified as "direct financing" or as a "multiple-element arrangement." (There is a grey zone in between those two possibilities, and further swirls, but for my brief essay I ignored that zone.)
If a financing company buys software for me and lends it to me, and if that is the only thing it does -- if it doesn't promise any upgrades or trouble-shooting services, and it doesn't deliver same -- if in the words of one authority the lessor "has no involvement with the software that is inconsistent with being a lender" -- in that case, the lease is a loan, and my lease payments are a matter of paying off that loan. The accounting proceeds accordingly, with a "Lease Receivable" item on the vendor/lendor's balance sheet.
But if it does promise and deliver upgrades and the like, then this lease contract is a "mutliple-element arrangement," more akin to a sale than to a loan. It becomes necessary to distinguish and value the different elements of the deal. This is true, too, of the loan of tangible equipment (you might lease me a backhoe with servicing promises). But distinguishing the separate elements in a software contract is apparently especially tricky, and auditors will require vendor-specific objective evidence (VSOE) of the value of the different components.
Zoom in further, and try to grapple with what VSOE means, and what are the consequences when VSOE can't be produced, and you get yet further Mandelbrotian swirls within swirls.
And there is the additional complication that software often comes embedded in hardware -- the "appliance" model. So the question of distinguishing among the elements of the arrangement may include the complexity of distinguishing the valuing of the dance and the dancer.
30 July 2010
Software
It seems that it would have been fun to be in San Diego on July 26, 2002 attending a conference on open source coding and hear this speech delivered.
Even the logistics of the speech were evidently a challenge. Bruce Sterling began to give this speech, "A Contrarian View of Open Source," and almost half way through a conference organizer interrupted to suggest they all move to another, larger, room.
"Can't you just throw out half the audience?" Sterling suggested. Which gives you an idea of the tone of the whole, too.
They got everybody settled in the new digs and the speech went on.
It's a better read if you know some of the cliches with which he is playing here -- if you know something about Lawrence Lessig's views on intellectual property rights, for example, or the context in which Eric S. Raymond introduced the expression The Cathedral and the Bazaar.
But you'll pick up the gist of it, from Sterling's own wonderfully skewed point-of-view, if you read.
And reading without reflecting is, as someone once said, a lot like eating without digesting.
Even the logistics of the speech were evidently a challenge. Bruce Sterling began to give this speech, "A Contrarian View of Open Source," and almost half way through a conference organizer interrupted to suggest they all move to another, larger, room.
"Can't you just throw out half the audience?" Sterling suggested. Which gives you an idea of the tone of the whole, too.
They got everybody settled in the new digs and the speech went on.
It's a better read if you know some of the cliches with which he is playing here -- if you know something about Lawrence Lessig's views on intellectual property rights, for example, or the context in which Eric S. Raymond introduced the expression The Cathedral and the Bazaar.
But you'll pick up the gist of it, from Sterling's own wonderfully skewed point-of-view, if you read.
And reading without reflecting is, as someone once said, a lot like eating without digesting.
25 February 2010
Toyota's electronics
I imagine that there are different possible ways of transliterating Japanese characters into the Western alphabet, and that at some point in recent history the "Toyoda" family went one way while the company that shares their name, "Toyota," went the other. Here's what a blogger says, but of course you will take it with the proverbial grain of salt.
At any rate, the testimony of Akio Toyodo, and of other high-ranking Toyota execs, was the center ring of yesterday's Congressional circus. This isn't a policy inquiry: more like a public shaming.
I have to say that, in accord with some of the members of the House committee involved, I have some curiosity as to whether this is a software problem. Toyota seems convinced it is a mechanical matter -- sticky gas pedals and so forth. But there is a lot of software involved in cars nowadays, and in particular there is a lot involved in the act of braking a hybrid.
There is (a) the software that does the pumping for you, making for anti-lock brakes, and (b) the software involved in converting the energy exerted in braking into electrical energy, thus re-charging the batteries, and (c) the software involved in the anti-slip. I suspect it is possible that these systems are interacting in some unexpected way in the few cases that have caused all the furor.
At any rate, the testimony of Akio Toyodo, and of other high-ranking Toyota execs, was the center ring of yesterday's Congressional circus. This isn't a policy inquiry: more like a public shaming.
I have to say that, in accord with some of the members of the House committee involved, I have some curiosity as to whether this is a software problem. Toyota seems convinced it is a mechanical matter -- sticky gas pedals and so forth. But there is a lot of software involved in cars nowadays, and in particular there is a lot involved in the act of braking a hybrid.
There is (a) the software that does the pumping for you, making for anti-lock brakes, and (b) the software involved in converting the energy exerted in braking into electrical energy, thus re-charging the batteries, and (c) the software involved in the anti-slip. I suspect it is possible that these systems are interacting in some unexpected way in the few cases that have caused all the furor.
03 April 2009
Plagiarism detection
Where there is a demand, there will arise a supply.
In the contemporary world, where any child with a research assignment can find a closely related paper on the internet with unprecedented ease, and then with a couple of clicks copy it to his own file and put his name on it, there is a great demand for plagiarism detection software. Teachers want to know, quickly and reliably, which of their students has done just that.
Apparently the two best known programs marketed as the answer to this prayer are: turnitin and Safe Assignment.
Unfortunately, there are still a few bugs in such efforts.
I have no profound point to make here, I'd just like to encourage anyone with any talent in the area of software development whose talents aren't already fully deployed to think about this as one field for their exercise. The teachers of the world could use your help. And market forces will make it worth your while.
In the contemporary world, where any child with a research assignment can find a closely related paper on the internet with unprecedented ease, and then with a couple of clicks copy it to his own file and put his name on it, there is a great demand for plagiarism detection software. Teachers want to know, quickly and reliably, which of their students has done just that.
Apparently the two best known programs marketed as the answer to this prayer are: turnitin and Safe Assignment.
Unfortunately, there are still a few bugs in such efforts.
I have no profound point to make here, I'd just like to encourage anyone with any talent in the area of software development whose talents aren't already fully deployed to think about this as one field for their exercise. The teachers of the world could use your help. And market forces will make it worth your while.
Subscribe to:
Posts (Atom)
