From: dpayton@qcinet.Gwinnett.COM (Doug Payton)
Newsgroups: comp.sys.hp
Subject: Re: HP and windows NT
Date: 12 Oct 92 15:32:57 GMT
Organization: Quality Consultants, Inc.

In article <1992Oct08.132656.29901@cadlab.sublink.org> martelli@cadlab.sublink.org (Alex Martelli) writes:
>dpayton@qcinet.Gwinnett.COM (Doug Payton) writes:
>	...
>:>The obvious counter to this is that, if there are already THAT many
>:>applications on platform X, then there is sure to be excellent competitors
>:>to the application you plan to provide.  For example, word processors and
>:>spreadsheets on PC's are a dime a dozen; could you compete there?
>:
>:The "customer application" argument is, certainly, only one of many
>:items to consider when picking an OS to write for.  Vast Competition can
>:be a show-stopper, to be sure, but Borland, for example, has been able
>:to overcome that.  Granted, not many small companies could duplicate
>:that feat.  
>
>Borland itself has definitely NOT "been able to overcome" keen
>competition in many areas - what's the market share of Quattro?  What's
>the market share of Sprint?  Note that spreadsheets and WP's were the
>specific examples I gave!

Vast Competition has -not- been a show-stopper for Quattro, and it has
become one of the foremost spreadsheets in the field despite it's
relatively late entry.  Borland -must- be making money on it, or
development wouldn't be going so full-steam-ahead (Sprint, as you point
out, is a fine example of what happens when an app doesn't sell well).
No, it doesn't have the market share of 1-2-3, but it's right up there
in the top 3.  -That's- my point.  Large companies are typically in a
better position to say "So what" to Vast Competition and make a bundle
on another product in what appears to be a saturated market than a small
company.

>:I was just countering the idea that developers should only write for an
>:OS that they like the tools for.
>
>ONLY?!  Never heard anybody propound THAT!  

While Sean McClinden never actually said those words, my impression from
his articles was that -that- was why he wrote for Unix.  

>If the developers are
>samples of "homo economicus", they'll develop where they project
>maximal [ (present-value discounted) revenue minus (p-v d) costs ].
>The productivity afforded by the tools used plays on both terms
>of the formula, of course; optimal tools deduce dev't costs AND
>enhance present-value discounted revenue by allowing faster time
>to market and thus, at least, anticipating the cashflow stream
>(fast time to market actually has much higher revenue-enhancing
>effects than this in most cases - any good modern microeconomics
>text on concurrent engineering will surely have a chapter or
>three on that...).

Now, ya' see, we do agree on this.  You've pretty much summed up my view
that tools, while important, are not the be-all and end-all decision for
platform choice.  
 
>:I can see your point for the most part, but I can forsee possible
>:problems when porting to platforms without the tools the developers have
>:been relying on.  Perhaps most of them may not be needed in the porting,
>:true.  There are certainly a myriad of special cases and situations that
>:call for looking at tools.  My initial reply was to the rather general
>
>Excellent tools are generally gradually ported from the platform they are
>first available on to other ones.  

Let's see how long it takes Perl to be ported to the HP3000, to test
this theory.  :-)  Actually, with MPE going POSIX, that -may- not be
all that far off.  

>:statement that developers don't need to look at the customer application
>:base, and to the additional general statement that they only need to
>:look at the tools that run on an OS.  Both, I believe, are not true in a
>:generalized form.  More often, a developer should look at other things
>:first.
> ^^^^^
>
>I dispute that "first".  Incidentally, in my worldmodel the developer is
>primarily responsible for the *technical* aspects of what she's doing,
>and is, one hopes, partnered by a sparkling marketeer with a market
>feel, as well as by some financial wiz who'll oversee the financing
>needs, etc.  Just as in the classical economic distiction between
>capitalist, entrepreneur, worker and landlord, it's of course possible
>(and typical for very small startups) for all of these roles to be
>actually played by the same person - good luck, then, in actually
>having all of the requested skills available rolled into one individual!

Agreed.  I'm thinking more of the overall decision by a company to
develop a product.  Of course, the techie will probably lean toward the
tools, but an educated and informed techie will certainly acknowledge
the other pressing matters.

>As a techwiz, my role in the strategic-planning stage is to evaluate how
>much it will cost to port or develop application X wrt platform Y with
>software Z, how well will it run under those conditions, and so on; NOT
>to guesstimate if Y's supplier will go bankrupt before we can market our
>product, or whether most potential customers are allergic to Z and get
>hayfever even mentioning it, and so on.

Perhaps, but a techwiz that is not informed will not understand the
concerns of the marketroid, and all that makes for are heated arguments
where neither side really understands the other.
-- 
Doug Payton -- Internet:  dpayton@qcinet.gwinnett.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"It is true that to err is human--
but it can be overdone."                                            Unknown
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.sys.hp