Re: What About Price vs. Performance?

Leif, I've had this discussion innumerable times over the last couple of years, 
and I'll state my opinion:

If you don't know what hardware your servers will be running on in the next two 
or three years, you have huge problems.  At the same time, with a decent 
message-based approach, give me a two-year lead time and I can port my servers 
to whatever machine I need.

So, the concept of server-side platform independence is, TO ME, a complete and 
utter waste of time.  Client-side platform independence is crucial, because I 
have no control over the client, especially in anonymous-client distributed 
applications like the web.  But I do have control over my server, and I'm doing 
my clients a disservice if I write code that runs slower on their hardware just 
so I can sell it to someone with different hardware.  SSA did that, and it 
killed their product.  Quite literally.  The new BPCS is a joke compared to the 
versions from 5-10 years ago.

So, to me, server-side platform independence is simply a way for software 
vendors to maximize short-term profit at the cost of performance.  As to the 
client side of it, if I were a corporate CEO, and my IS manager told me he'd 
rather have slower performance than take the time to select the best hardware 
for the job, I'd be looking for a new IS manager.

But that's my opinion, and you're not going to shake it, so let's leave it at 
that.

Joe


---------- Original Message ----------------------------------
From: "Leif Svalgaard" <leif@leif.org>
Reply-To: MIDRANGE-L@midrange.com
Date: Thu, 5 Apr 2001 10:14:36 -0500

>From: Joe Pluta <joepluta@plutabrothers.com>

> Not until you show me a business server that does the job better, Leif.  It
makes absolutely no sense to me to make my server-side code portable at the
cost of performance, just for the sake of being portable.  That's a red
herring and a losing game, and it cost some major companies their livelihood
(look at System Software Associates).

Joe,

We approach this from different sides. You from the developer's and I from
the customer's.
It does make sense to make a major application portable (and it does not mean
automatically
poorer performance). Is it not you that keep telling me that your Java stuff
will run ANYWHERE
and that that is a benefit?

If your back-end is also portable you can sell your application to customers
who do not
wish to run a antiquated equipment (before you flame me: "perceived
antiquated"). You
narrow your market by not being portable.

The reason many companies fail trying to make portable applications is that
they
often do it wrong. The classical mistake is to achieve "portability" by using
COPY
books, or #ifdefs, of header files,... This is unmanageable. As you well know
you achieve
portability by going through well-defined interfaces at the correct divisions
into tiers.

Leif



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---