From: martelli@cadlab.sublink.org (Alex Martelli)
Newsgroups: comp.sys.hp
Subject: Re: HP and windows NT
Date: 8 Oct 92 13:26:56 GMT
Organization: CAD.LAB S.p.A., Bologna, Italia

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!
Their original success came from very good evaluation that the
market potential for a CHEAP Pascal compiler on CP/M and MSDOS was
huge, AND the competition in that market segment was sleepy (fat
and happy, aka Mickeysoft, and more generally overpriced for the
target audience).  Sure, you CAN find success stories of companies
deliberately chosing to become the N-plus-1'th supplier, for N
already very large, in some high-demand market segment... NOT very
many, though!

: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!  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...).

Of course, man does not live by bread alone.  The true costs of
developing with, or rather UNDER, Mickeysoft tools, for example, cannot
be adequately summarized by considering how much longer it will take
you; it really isn't enough, even, to add the present-value discounted
cost of all the Maalox (TM) and Zantac (TM) you'll have to consume for
the ulcer they will give you.  At some point, the question of the
self-respect a person owes h{im,er}self and h{is,er} professionality
must come into account, just as one wouldn't choose prostitution or
drug-dealing instead of software engineering by just considering
revenue streams and risks to health:-)

:>The case in which a developer chooses a platform depending on the tools
:>available for it, is, instead, typically when an innovative thing is
:>planned, one that may well be later be ported elsewhere, but for being
:>born at all requires the very best development environment.  
:
: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.  Particularly when those tools are
essentially an API (what you need for the porting itself) you can at
times do the porting yourself, by "clothing" an available horrendous
API (such as those a firm with a name starting by M often designs) by
what's needed to emulate a saner one (under which you can develop).

Many more potentially world-beating innovative applications are
stillborn because the development effort (including tools needed!) was
undervalued, than get "stranded onto the wrong platform" and "can't be
ported" for lack of tools, if the demand for the ported product is there.
(at least for app's developed by people with a minimal flair for software
porting, that is - unportable parts to be recoded properly encapsulated
onto modules to be rewritten, etc).

: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!

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.

Thus, while it would be IDIOTIC for me as a developer to ONLY consider
the tools' quality (I must also clearly consider the platform's technical
details as an application-DEPLOYMENT platform, NOT just as an application
DEVELOPMENT one!), it IS in most cases the first and foremost aspect
(if the platform makes for speedy development, it should be at least
just as speedy in running the finished code in most cases; if the display
is sharp and wide enough for the dev't phase, it will generally do for
the usage phase; and so on, though one must check for possible exceptions).

:>A similar
:>case, minus the porting, is when you have the target of an in-house
:>application, one that will not need to be marketed; in this latter case,
	...
:All this is true in that specific set of circumstances, but there are
:also many situations where the choice of computer, especially in larger
:corporations where policy on such things are made, has already been made
:for you.  

Sure, but you as a technician can still point out how much more
effective it would be to change application development and/or
deployment platform.  Many times I have written code that HAD to be
deployed under MVS for compelling reasons (yes I was an IBM'er in a
former life...:-); this has never stopped me from arguing with my
management, generally successfully, that the *development* should take
place on VM / on a PC / on a Unix box, due to the much better quality
and availability of tools there (editors, debuggers, procedure
languages, whatever), as long as the final porting to MVS was taken into
account in the cost-benefit analysis.
As a final resort, one may resign (no I'm not an IBM'er any more...:-)
rather than carry out a corporate decision that one perceives as utterly,
irretrievably wrong-headed - whether the irreconciliable contention be
on platform choice, or many other possible technical discrepancies.
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 
Newsgroups: comp.sys.hp