Need a book? Engineering books recommendations...
RE: COMP:Freeware?[Subject Prev][Subject Next][Thread Prev][Thread Next]
- To: <seaint(--nospam--at)seaint.org>
- Subject: RE: COMP:Freeware?
- From: "Dennis S. Wish PE" <wish(--nospam--at)cwia.com>
- Date: Mon, 12 Oct 1998 18:56:42 -0700
I don't think I'm really arguing this position with you. However, Avansse and FastFrame were not intended to be Freeware. Enercalc intended to market FastFrame, Avansse is still being marketed and supported. Avansse's offer was only meant to be temporary - possibly even a resolution to a past problem. I don't place either in the same category with freeware and shareware products. I think what you said of freeware and shareware products is, in some ways, valid. I just don't agree that this applies to Avansse or FastFrame. I would place these products in a category of useful engineering tools which are presented as promotions or used as marketing tools. I, truly believe that Mike Brooks gave FastFrame to the engineering community as a well intended gift and not, as a means to provide restitution for any problems. Was it a marketing decision to gain over his competition - I don't know. If it was, then his decision to give it away was a marketing decision and has no bearing on the accuracy of the product. FastFrame was not the marketing focus of Enercalc - the diverse Enercalc library was. If anything, FastFrame became a good promotional tool to introduce potential buyers to Enercalc quality and product line. Eagle Point did this with their Retaining wall software a couple of months ago as do other vendors. Avansse is not free - nor is it shareware. With the exception of what Boris may have considered a "settlement", Avansse is only available through sales. If Boris wants to continue selling and marketing his product, he needs to "clear the air" and rebuild the faith that some have lost in the product. I don't feel qualified to judge either product except in my usual need for the design of simple frames. In this case - Avansse's results matched those I obtained with Risa2D, FastFrame and STRAP - which validates the credibility of the other products at the same time. I did have a problem with the AISC code check, but before I labled it as a bug, I contacted tech support who asked me to submit my model (data file). They explained my problem, which was my lack of understanding of the types of analysis that the software can perform. It was not a bug (as I feared) and I was at fault for making an improper assumption as to what the software would do without consulting the manual that I downloaded. You describe a "bug" and I would not challenge your explanation. However, when I marketed a software product (which I wrote), I discovered that the problems virtually all users had, was attributed to the perception of how the user thought the software should work rather than how I designed it to work. For example, my software did pier analysis in a multi-story URM building. The weight of the wall was automatically accumulated by the software, whereas some of the users believed that they needed to calculate the weight of the wall manually therefore, duplicating the input. What I cautioned you about was creating a perception of a *bug* where one might not exist. I have reviewed software for my pleasure as well as a service for "SEAOC Online" for over 6 years. One of the lessons I learned early was that structural engineering software represents a very small percentage of the software industry. There are very few engineers with the ability to create the tools we need and who have the ability to properly market them. The last thing I want to do is bury an engineer who is a creative programer on top his or her engineering skills. The community is small enough to literally drive the developer out of business by one bad review. I wanted to provide encouragement to developers, who have a potentially useful product - one that would benifit your practice as well as my own. It is very difficult to anticipate what part of the market that the developer intended to capture. Sometimes the developer is unaware of another portion of the market they have overlooked and our public input can give them the incentive to change the software for a wider range of users. I would much rather review the software from a perspective that it either has or has not achieved its potential and what I perceive the potential of the software could be. Whenever possible, I will suggest in the review what features a practicing engineer needs, what tools will increase productivity, what the output should contain that a plan reviewer will find easy to follow. It is also helpful for a developer to listen to the users of his product and choose a direction that the software can evolve. I rarely review a product for accuracy, which I, along with most other reviewers, assume from the start. In most cases we do not have the time to check a product for accuracy in all possible usages. I will not address issues of *bugs* on a public forum. These are issues that need to be addressed by the vendor with the user who has personal experience and can recreate the problem. I would be wrong to publish reports of *bugs* which have the potential of doing irreputable damage to a small company by attacking the software credibility. I think this is ethically wrong and is best left to tech support. However, I don't agree with the developers who are not willing to alert their users of problems that arise either by mail, private forums or other means. I don't think that admitting the existance of *bugs* is worse than ignoring them - but this is one decision that I believe belongs with the developer - a decision I must respect. If the reliability of a product becomes an issue, I won't review it. If it is not corrected in a timely fashion, the sales of that product will suffer - without my help. In my opinion, this is the greatest threat to the future of a software product - the loss of faith by registered users. There are not enough engineers in this world that a developer can rely upon replacing when he starts to ignore the use of his product in practice. I will, however, critise features which may not be intuitive, or confusion that could lead to misuse of the software. In any case, I will not review a product that I have , as Bill Polhemus's stated (and I paraphrase),not had used in actual practice. Bill was absolutly correct that the only way to really know a software was to use it in practice - this is why I request full working copies from vendors who agree to let me review their product. A product can not be judged fairly through a demonstration or press-release. It's very important for anyone who evaluates software to do so with as if their own project relied upon the accuracy of the software. This alone requires full access to technical support and full documentation. In my case, my investment in time to properly learn a software product is more than most are willing to invest. However, I do this as a service to SEA and, admittedly, I get a kick out of *playing* with the product. Hopefully, you and the rest of the community who read my reviews find enough information in my article to help you evaluate if the product fills a need in your office. I would not want anyone to purchase a product blindly, but my review should be weighted with some personal research by the potential buyer. I'm sorry to fall into my usually long posts and hope I have not bored some who choose to read it. However, I feel strongly that we, as a professional community, have two choices - 1) create our own tools OR; 2) recognize the unique ability of those who have the engineering and programing skills and encourage them to create the tools that will benifit each of us. Finally, I believe strongly that we are at the very first rung of the ladder of engineering software evolution. There is much to accomplish and we need to develope relationships with the developer - and guide him/her in the process as to what will meet our specific needs today and tomorrow. Respectfully Dennis Wish PE -----Original Message----- From: Sibco6756(--nospam--at)aol.com [mailto:Sibco6756(--nospam--at)aol.com] Sent: Monday, October 12, 1998 3:21 PM To: seaint(--nospam--at)seaint.org Subject: Re: COMP:Freeware? Dennis Wish, you wrote << Please be careful about the term "bugs" since the majority of "bugs" that exist in software are actually the users lack of understanding on how to use the software. I am not saying that Sib has a valid or invalid claim, but would not want to make the implication that free software is any more or less "buggy" than the software I paid for.>> In all actuality, that is EXACTLY the claim I am making. Though you may disagree, my experience has been that I find more bugs in the so called "freeware" and "shareware" than I do in software I have payed for. I am sure that one can find exceptions to this, but I believe my experience to be more common than not. There is also usually a noticable difference in the quality of the support one recieves between "freeware" and software that is paid for. Perhaps differently than you, I am not bashful about calling a "bug" a bug. If the software manual says it does something one way and the program performs the said operation in another manner, than to me this a "bug". If I must spend too much time worrying about the bugs in the software I use, then it has lost it's use to me to improve my productivity. Apparantly differently than you, I also do not have the leisure time you say you have to "play around" with all the new softwares that come out. I prefer to find what works and to "stick with it". -sib
- Re: COMP:Freeware?
- From: Sibco6756
- Re: COMP:Freeware?
- Prev by Subject: Re: COMP:Freeware?
- Next by Subject: RE: COMP:Freeware?
- Previous by thread: Re: COMP:Freeware?
- Next by thread: Re: COMP:Freeware?