Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Y2K (Year 2000) Stocks: An Investment Discussion -- Ignore unavailable to you. Want to Upgrade?

To: TEDennis who wrote (7163)	10/27/1997 11:27:00 AM
From: Risky Business	Read Replies (2) \| Respond to of 13949

AAAAAHHHRRRRRGHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Sorry, just a little tension break had to do it.

To: TEDennis who wrote (7163)	10/27/1997 2:00:00 PM
From: Hoatzin	Respond to of 13949

TED, thanks for confirming my suspicions <g> . Here's an excerpt from a letter I sent to briefing.com about their Vertex article. (Hey, they actually asked for feed-back...) Aside from the "bit-level" discussion of how Vertex might work, I thought there were some things in that piece that that people were ignoring or accepting at face value.. <SNIP> Let's get the roll-on-the-floor-funny stuff out of the way first. You wrote: "Cost to the end customer is yet to be finalized, but is currently planned at around $0.15 cents per line of object code. This is significantly cheaper than the current norm of $1.00 to $2.00 per line of source code, even considering that source code might condense to object code at a rate of 3 to 1. Converted to source code, BMR's rate is still only $0.45 per line." Wrong! If one "object line" costs $0.15, and three "source lines" are compiled in to one "object line", the charge per source line is FIVE CENTS!!!!! (This assumes that object code can actually be measured in lines, which it can't.) Now for the serious stuff. Philosophical issue number one: Testing. You wrote: "Additionally, a significant reduction in testing time is expected as compared to remediation and recompilation of source code. Since none of the original functionality of the original program is altered, the only testing required is of results of the operations. Bemer recommends creation of output data files from original and Vertex-enhanced code which are then compared. Early testing shows no differences." If the pre-Vertex programs would have failed to correctly process dates later than 12/31/1999, the expectation is that they will work correctly after applying Vertex to them - THEREFORE THEIR FUNCTIONALITY HAS BEEN ALTERED! And therefore they should be tested. Thoroughly. Comparing output files from before and after is only one step in a normal testing procedure. But using what inputs? Using current data may not find errors in processing dates after 12/31/1999. So future data is needed. How much? With what range of dates? And what about the special month-end and year-end processing? And what if the output of the program is not a file, but a screen, or a report, or a check? My point here is that applying Vertex is no different than any other massive change to production software for the Year 2000: it implies a testing project of enormous scope. Somewhere else in your article, you quote Bemer as saying "We can't fix stupid programming." Well, here's an insight from someone who has debugged his share of abends at 2 AM: there's an awful lot of stupid programming in production today, and you'd better test for it. There is also a lot of code that could be described as fiendishly clever, devious or cute. Applying the Vertex "fix" to the vanilla stuff does NOT remove the requirement to test. Philosophical issue two: Effect on other Companies. You wrote: "...any large company is likely to at least try BMR on some portion of their system. If it works, and the code becomes Y2K compliant in less than a month, BMR is likely to squeeze out every other vendor." This statement makes it obvious that your writer does not understand how software is acquired or managed in corporations. Most MIS Directors do not just "try" something on their systems. This type of software, for the most part, is sold, not bought. Identifying and contacting the right techies and VP's in a prospect company can take a long time. And even if the techies want to bring in a product, getting over all the financial and technical hurdles to an actual implementation can be a long and excruciating journey. Based on the nature of the marketplace and the laws of physics, I am going to make a SWAG that BMR (even with an army of licensees and franchisees) will not be able to pitch their product to more than 5% of the market over the next two years, and that less than 5% of those prospects will try the product. Even that is an absurd projection. The market for remediation products and services is just too huge and too diverse for any participant to squeeze out all the others. "The non-exclusive franchise model means that the sky is the limit deploying the product." The sky is the limit? Where have I heard that before? This is starting to sound like a hype job. I would suggest that time, space, money, fierce competition and the vast, fragmented nature of the market will place severe constraints on the success of this product.