Need a book? Engineering books recommendations...

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

RE: My personal Software "Wish" list

[Subject Prev][Subject Next][Thread Prev][Thread Next]
One problem with O-O software is capitalism. Each vendor wishes to capture
as much of the market as the law will allow (Microsoft is pushing this limit
right now). To accomplish what you suggest, and I think it's a great (albeit
somewhat impractical) idea, is to first unite vendors willing to work out a
standard. We've seen how successful the modem manufactures have been with
V90 as an example. Still not working, but then who cares any more.
The first move to O-O has been the adoption of a Windows for a common
platform. We are still not 100% of the way there as yet.
I've been involved in a private conversation by one software vendor who
wishes to understand what we are looking for in coordination with output. It
boils down to some of what you suggest - better integration between
programs.
There are two problems - but since I am not a programmer (except in
spreadsheet) I don't know how big a problem this becomes.
First, most programs seem contained. You can easily tell a program created
in Visual Basic or C++ compared to a program written from the ground up in
programming language. BTW, this is one of the biggest problems I see with MS
products. Wouldn't it be nice if Outlook 98 could be loaded in smaller
modules and uses only as needed. However, when they are closed down, other
components that share similar information would be updated. Less memory
demand, faster loading etc.
Wouldn't it be nice if you could pull one module out of Enercalc, StruCalc,
Woodworks, etc and share information from each one by OLE/2, cut and paste
or by using a common container like Binding or MathCad's Connectrix.

You are correct that there is a lot to do to find a common ground that will
make software's interact better. The other issue is the desire to create a
completely interactive, integrated software than will provide complete
design and analysis as well as drafting support. I believe most of us would
like this, but realistically, few of us will be able to afford the
technology.
I had written (SEAOC Online) a few years ago about such a product produced
by a company in Boulder Colorado. I can't think of the name but the idea was
to completely integrate the design and detailing process. It failed in
anything but the simplest block design, but the goal is still valid.  We are
starting to see bits and pieces of this in Eagle Point Software, Ram
Analysis, and a few others I forgot to mention.
Keymark Industries was the company in Boulder that was working on the
integrated package. Keymark was known for their development of Trus Joist's
TJ beam program.
The problem was how to market. Sell the software, Lease the software, or
network it and charge for each run. This still might be a solution worth
considering.

How about some other ideas.
Dennis Wish

-----Original Message-----
From:	Szuchuan Chang [mailto:szchang(--nospam--at)pacbell.net]
Sent:	Friday, July 31, 1998 12:02 AM
To:	seaint(--nospam--at)seaint.org
Subject:	Re: My personal Software "Wish" list

I wish that in a short period (3-10 years) we can unlock the real power in
the
engineering softwares.  Software created these days is too fragmented.  Each
vender has his own system, database, and GUI interfaces.  As I learned from
my
programming teachers, the method we are accessing designing software is
becoming
obsolete.

Engineering software should be designed as components, like the way we buy
plywood and 2x4s from lumber yard, rebars from steel supplier, and nails
from
hardware store.  If we can spend the time to convert our wish lists in to
specification for the different component of design, we can require that the
software supplier meet the our requirement the same way we specify the
strength
of our concrete mix.  After trial and error, we will get many of these very
useful basic components (called classes) to be standarlized just like our
specifications.  They call this kind of event "Object-Oriented (O-O)
Programming."

We want to see better software in the future.  We better get the O-O design
started in structural engineering field.  Software is rather expensive these

days because each design team has to re-invent all the basic building blocks
in
their program.  Many very good ideas die.  O-O design does not require that
venders give up their source codes.  They can publish their methods in
"header
files" (think about your supplier's catalog).  As far as I know, C++ and
JAVA
are leaning heavy on this technique.  For example, the Microsoft Windows
Program
evolved from MIT's X-windows.  Once that is done we don't have to rewrite it
everytime.

Once we got these components, we can link them together the way we want in
much
shorter period.  There will be new ways of putting components together in
the
future with the advance graphic user interface to meet our need.

Engineeing softwares will only become more important for us from now on  My
knowledge in this area is very limited.  However, I can see the need of
having a
information clearing house for the designers and the users.  It only get
better
when there is a forum to exchange ideas.  We can use the same energy that
engineering clubs employed 70 years ago to start the implementation of
structural design codes.

Will the engineers in SEAOC take up the challenge?

Sam Chang, SE
Cupertino, CA

Dennis Wish wrote:

> Joe, it's still a good sales pitch. Again, don't misunderstand. I'm not
> knocking Eagle Point or any other vendor. My point is one of knowledge of
> market place. Your comments are ideal for formal office settings where
there
> an accounting practice which allows for profits to be divided into
> investments and fed back into a companies growth potential.
> My points were aimed at the growing number of independents who deal
strictly
> on a cash basis. It's true that each of us needs to consider investment in
> our futures, but this generally means life insurance, health coverage,
> retirement funds, taxes and hardware investment upgrades. The hard fact to
> face is that if it is a question of spending $1,000.00 for a software
which
> you may use or spending the money on your family - the independent will
opt
> to complete his work with either the tools at hand or by manual methods.
> Look, I'm not saying that we are destitute by any means, but small offices
> rarly yeild excess cash flow on a steady basis.
> The only way for this growing market to afford the tools is by creative
> payment plans (spreading the cost of a year or two depending upon sales
> pricing), reducing features or the size of the model in an effort to
reduce
> the sales price, etc.
> I'm not sure what your add-in for Intellicad will cost the engineer. If
it's
> more than the software, you will have a potential buyer wondering why he
> should pay more for an add-on than a small full-featured cad package.
>
> I feel that this is sounding negative and I don't intend for it to be.
From
> my experience and discussions with other software companys, I generally
come
> up against a brick wall because the representative is wearing a suit and
tie
> and represents a company with growing assets.
> Possiby we are not the market for these people, but as the number of
> independents grow we will have to be targeted at some point or another.
>
> To be brutal, let me ask you why I should put together a package of three
or
> four modules to do three or four tasks when I can purchase an integrated
> library for less than the cost of your three or four?  Joe, I'm stepping
> over the edge here assuming that the cost per module may be around $150 or
> $200 per tool.
>
> I'm not trying to open the door for marketing of Eagle Point alone and
would
> welcome other software vendors to jump in. I only ask that you stick to
the
> marketing philosophy rather than do a commercial for your product.
>
> Thanks to Joe for paricipating in this.
> Dennis