Need a book? Engineering books recommendations...

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

RE: SAP2000, RISA3D, and STA

[Subject Prev][Subject Next][Thread Prev][Thread Next]
I would like to caution all of you in your comments. IMHO, I do not feel that it is appropriate to post bug reports on this list unless the problem has been verified as a bug with the vendor. Bill's example appears obvious, however, the comments made about Risa3D do not. From the standpoint of a post software vendor, most of the "bugs" reported by users were due to improper assumptions in the modeling phase of the program. In one instance, a fellow employee "assumed" that my program followed the same methods of analysis as she was used to performing. However, I had to make comprimises to the methodology in order to accomodate the spreadsheet formula's. Although my approach was conservative, it was diametrically opposed to the methods that she used. When I pointed this out, she blew up at me in front of other employees (not a generally good move as I was the only licensed engineer on staff). My method accumulated wall area's from top story down - her method added the areas at each lower level to what the computer showed (essentially) doubling the lateral weight and dead load in of the wall in a pier analysis). 

My advise is to first notify the software vendors technical support to acertain if the problem is a bug. Give him a chance to rectify the problem or point out your flaw in engineering assumptions and input. Indescriminently assuming a result that does not match your own is the result of a "bug" can be very damaging to the sales of that product - even if you are wrong. The rumors spread like wild-fire and people forget the followup conversations that my justify the product. Instead they associate it with an unreliable product.

In my own opinion, I think that each vendor should publish a bug report and report of known conditions that may yield inacurate results. Some vendors feel that this is paramount to suicide, but I think most of us are under the opinion that we would respect a vendor that forewarns us of impending problems and works to rectify the situation as quickly as possible. If a bug report is to be issued, then I believe the vendor might consider posting it on his own web site, or forwarding an update to the SEAOC web site or even make a short post on the list to alert users of a reported problem that has been verified. I don't think that a vendor who openly identifies a problem in his coding is doing any more than strengthing his relationship with his user base. Those that would drop a product without due cause other than the knowledge of a bug will act the same way with a competitor's problem.

Finally, no software should be taken on it's own results. This is foolish. The engineer or designer should be knowledgable enough in the materials that he uses to have an intuitive feel for the results yielded. If he/she does not, then they should be doing the analysis manually until they develop the skills. Developers work hard to develop a life for their products and to insure accurate results. They tend to be walking a tightrope constantly and are under scrutiny by those that have personal favorites in other area's. I may love the idea of working with a piece of software, but when I find that it requires different philosophy of input and new knowledge of keystrokes I tend to compare it to my old program and be more critical with the new. Like an old pair of shoes that you can't get rid of - you tend to stay with what you are comfortable with and reject programs that force you to do things in a new way.

One more comment - If it is indeed a bug and the developer refuses to correct it or address it in the public, feel free to document it and post it.  Mind you, this is only a last resort to protect others that might fall into the same problems you have had. Most developers are honest enough to correct problems immediately so I doubt that you would have to resort to this drastic measure too often. My comments are related only to bugs that cause incorrect results and are verified to be in the programing. 

Simply be as careful publically labeling a software as "buggy" the same as you would labeling another engineer as incompetent. Labels stick past the time when they are removed - there is always scraps of rumors left (metaphorically speaking).

Dennis Wish PE

<<application/ms-tnef>>