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 : CSGI ...READY FOR TAKE-OFF! -- Ignore unavailable to you. Want to Upgrade?

To: tech who wrote (1621)	12/17/1997 2:33:00 PM
From: David Eddy	Read Replies (1) \| Respond to of 3391

Tech - names of the tools used and how they did not meet the expectations Good, reasonable question... but a bit simplistic. Take something as simple as a hammer... at my local Home Depot there are 40 different types of hammer in the display. Something as simple as a hammer. For software tools, there are at least three major variables: 1 - the problem set or technical environment 2 - the tool users skills/knowledge/experience 3 - the tool Actually there's another, greater variable... management's attitude toward providing its worker bees with proper tools... but we'll avoid this for the moment. In the context of CSGI, as TED explained you're really not talking about a tool. What CSGI has is proprietary bunch of stuff... by their own admission it has no front-end. Believe me, this is a very critical hurdle in todays expectations of Windows GUIs. Staring at a command line prompt is pretty intimidating. But anyway... 1 - the problem set... where is the problem code running? It sounds a heck of a lot easier than it is in reality to "just download the programs to the PC/workstation". If the client is not familiar with such processes, moving code from one box to another is a big deal. 2 - skills of the worker... how good is the driver? At 25 year old Unix hacker is going to have a different reaction to a power tool than someone comfortable with ISPF. 3 - the tool... how fit for purpose is it? How well trained is the tool user? You'd be amazed at what people try to do with inappropriate tools. Typically what happens in large companies is that a tool buying committee goes off & buys a tool because there's money in the budget. Whether or not that tool is appropriate for the problems & skill levels at that site can be a real crap shoot. It is pretty typical for the tool buying committee & the tool using community to work entirely seperate from each other. Dumb, but true. Short answer to a lenghty problem... - David

To: tech who wrote (1621)	12/17/1997 9:21:00 PM
From: bistineau_la	Read Replies (1) \| Respond to of 3391

<I think he needs to call ConSyGen and see it CSGI's tool will perform better than the ones he has used. Maybe he can send them some work.> I'm afraid that I'm not at liberty to discuss which tools I have used. I will say that I work with a major player in the computer industry. Tools are obviously valuable in doing Y2K work and all tools aren't equal. I am not here to say which tools are most effective only that claims of 100% are NOT TRUE. Tools are probably of more value in assessing code than they are in doing remediation. There could be better tools than the ones that I have used, but I will continue to say that Y2K assessment/remediation will be very labor intensive and that a tool that correctly does 80% is very good. Some tools require human intervention/direction when making code changes. The more human direction that is given, the more likely that the tool's decisions will be correct... Julius