RAD Studio 2007 Updates, SOX, Revenue Recognition
In the past few weeks, I’ve had several customers and field testers ask why we don’t talk in detail about any of the updates we are working on as we used. I can understand the confusion, it’s fairly frustrating on the development side too since the more folks we have jump in and join the field test to test any upcoming updates, generally the better the updates are.
There are folks who ‘blame SOX‘. Well, I’ve only read several articles on section 404 compliance so by no means an expert. Is seems at least partially true - the issues centers around revenue recognition and how promising/describing an upcoming update means the product you released was not what customers paid for. It appears one intent is to avoid bait and switch techniques, and customers are supposed to be protected.
Even Apple had some ‘interesting times’ adjusting to the new rules. Another article I ran into described examples and scenarios of Revenue Recognition for Software Products with Multiple Deliverables - however it’s unclear even in that description if patching a failure discovered prior to or after release impacts revenue recognition. I feel for our accountants, I really do.
It gets fairly complex at this point, but our financial boys rightfully are cautious and it can be extremely expensive to recalculate revenue. Plus, you can get in all sorts of trouble with the SEC , fines and costs associated with audits. Ouch!
So I asked around about what we could say about updates. Not much unfortunately. I can acknowledge we’re aware of issues, which we also do via Quality Central , just cannot describe what’s on our update lists, general schedules, and certainly no promises to fix any specific bugs. Kind of hard to instill customer confidence, right? Especially for CodeGear who has a big focus on developers, and showing that we care.
We can demonstrate with results, and thinking about it - we can talk more openly in the private fieldtest where those joining need to sign an NDA. For those who want to understand and see what’s in the works…
Click Here to apply to the RAD Studio fieldtest
Anyways, it’s something for those interested and want to peek in more directly. We do care and we really are on a quality focus.
October 12th, 2007 at 5:40 pm
Personally, I cannot see how effectively forcing a company to be LESS open with its customers and the public benefits anybody (except perhaps lawyers)…
SOX definitely needs some darning. (Sorry, I couldn’t stop myself)
October 20th, 2007 at 11:53 pm
0. Thanks a lot, Chris, for your diligence to write this. Really appreciated!
1. My son, imho, perhaps is better to add a new state to QC: ‘In progress’ - like many bug-trackers have. This will be quite effective, also (internally) for you, especially if you’ll add another field called ‘Responsible’ or ‘Asignee’, but mainly for the community which will see, firstly that you do _try_ to handle their requests (which, imho, is the _most_ important thing) and, more, they’ll see the human behind. This has also two important consequences: a.) the community will see that really is someone there which cares for this and is at pains to do it (or, oh well, it’s supposed to be..). and OTOH b.) publishing the name of the one who’s responsible for that feature is a /very/ strong goad for that man (men) to do his job right, as you probably know, because this is a classical piece in product management. As an aside, is known that it was one of the main factors for Adobe to achieve their quality standards the fact that every member from the team is written in the splash screen.
2. Some ‘Field Test’ shouldn’t be opened also for Tiburon? Think about it…
just my2c & hth