> Allen Bauer wrote:
>
> Sorry, I have to call BS on this one...
>
> This 'problem' only existed for a year once the accounting method
> changed. As a programmer, you should easily be able to figure out
> the paradigm.
If, and only if you can survive that year with markedly lower revenue.
Also, it assumes that there are enough customers jump on that bandwagon.
> At the beginning of the time, you folks went from 'booking all
> revenue' to only 'booking one-twelfth' of the revenue. However, a
> year later you would be booking 1/12th of the new revenue from that
> month, 1/12th of the revenue from the month before, 1/12th of the
> revenue from 2 months before, etc., so that the total revenue booked
> one year after the accounting transition would 'show' as the full
> value of revenue that was being booked monthly a year previously.
>
> The only result that SOX has at this point (more than one year after
> you changed accounting methods) is to SLOW the impact of revenue
> changes. If you have a stupendously large month, that change will be
> seen more gradually -- but the good news is that so is a dip.
>
> So, you're not dealing with any differences in income, all of this
> nonsense about 'measuring the health of the company' doesn't relate
> to the 'real' measure of the company -- i.e., how likely is it that
> you will retain your paying customers?
Correct. However it is the *transition* to that model that is what is
costly. As I stated in other posts, we cannot simply tell the creditors
and the investors, we're going to not be able have the same operating
profit for a while... We agree that the *outcome* is what is desired,
the problem is that the path from the current model to this new model
is no simple task. Our CFO would have a conniption.
> I've been on SA for a while now, but I'm beginning to regret it. I
> literally never even installed RAD Studio 2009, because there were so
> many issues to be worked out in it when it originally made the
> transition to Unicode. RAD Studio 2011 (or whatever it will be
> called) will very likely be the same -- there is no way I'm going to
> trust a complete re-write of the compiler before I see others spend
> several months 'wringing the bugs' out of the product, and the
> likelihood is that (as with 2009) they won't be fixed until the NEXT
> iteration of the product.
>
> So, at this point, being an SA customer brings me no real benefit --
> I actually feel very much like I'm gambling. And frankly, I am. I'm
> gambling that a release will come out within the time frame of my SA
> period, and I'm gambling that the release will actually be
> usable/useful.
That's the whole problem. Too many people think SA in its current form
is more like playing craps than being sound business strategy. How do
we fix that without giving our intestors, creditors, and CFO
indigestion?
> Embarcadero really needs to revamp what SA means if they want to
> retain folks longer term (retain as customers of SA, not overall
> customers). Blaming all of this on SOX doesn't go over well...
On this we can agree. We need find some way to make SA more attractive,
since clearly the "you may get the next release for free" line isn't
sustainable long term. The SOX angle still plays a key role, whether or
not you believe it.
--
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer