On Fri, 2003-09-26 at 03:46, Giorgio Bellussi wrote:
> do you really want a production environment based on an 0.x product?
Short answer: why not?
Long answer: this rhetorical (and rather imprecise) question irritates
me. Please excuse me as I vent a little.
You might as well ask if one really wants a "production environment"
based on a wintel platform. Or a non-raid disk. Or a non-ECC memory
subsystem. Or a power supply not backed by generator. Or on machinery
not configured for fully redundant failover, with geographic
separation. Or a bare-bones DBMS that isn't ACID compliant. Or a
remote network that isn't diversely routed. Or a security mechanism
that isn't audited frequently. Or a nonexistant or easily circumvented
change management regimen.
These are all value judgments, and depend on your local definition of a
"production environment". A production application could be as simple
as webifying call detail records provided by your PBX. At the other end
of the spectrum you could be launching a two billion dollar orbiter.
(I'm guessing you fall somewhere between these extremes.)
Have you ever read _The Soul of a New Machine_ by Tracy Kidder? It
chronicles the creation of Data General's "Eclipse" line of computers,
the conflicts among management, marketing and engineering, and the
tradeoffs and compromises that were necessary to bring the project to
completion. The principal engineer, Tom West, was quoted as admitting:
"Not everything worth doing is worth doing right."
My personal blog and mail server are production applications - at least
for *me* - running on a P-II system with SCSI disk, ECC memory and some
carefully chosen beta software. A community theatre group that I
support keeps a production web server - also a P-II system - which had
an uptime of 611 consecutive days before being relocated. It also runs
some carefully chosen beta software.
Over the years in my professional mainframer life I have participated in
a number of beta programs for well-known manufacturers, and have
committed "production" to many of those products well before they became
generally available to the public with version 1.0 stickers. Of course,
we only did this after careful evaluation and due consideration, and not
all beta projects made the cut.
The point is that whether your "production" system is a personal blog or
a realtime warehouse management system, you are obligated to choose
components according to their observed performance and your
requirements, always being mindful of Tom West's advice: you don't need
a Mack truck to bring home groceries.
Do not trust version numbers. Version numbers are thin fiction. I've
seen crappy beta software, and great beta software. I've seen crappy
and great release-level software too. There is fundamentally NO
DIFFERENCE between beta code and products with 1.x version numbers.
Version numbers lie.
You do yourself and your organization a disservice by arbitrarily
dismissing 0.x software. You might as well avoid odd-numbered releases
(which advice I've heard from ignorant but otherwise well meaning
people). Another silly rule-of-thumb is that you should avoid release
numbers ending in zero. Some people like to wait for the second formal
release of a product before they'll look at it, and some others wait for
a year (or some other magical unit of time) after GA to allow a product
time to "settle down".
This is either lazy or superstitious, but it's not good business. If
you rely solely on marketing people's version numbers to decide whether
a product is suitable for use in your application -- well, you must have
a pretty easy job.
--
David "switching to decaf now" Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]
