Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

RE: COMP:Freeware?

[Subject Prev][Subject Next][Thread Prev][Thread Next]
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