RE: (PM) Clarification of POW

Scott A. Morris (samorr@inter-connect.net)
Mon, 20 Jul 1998 21:53:32 -0400

Karl - You get my vote for president!!! Look out for the interns.

-----Original Message-----
From: owner-portmaster-users@livingston.com
[mailto:owner-portmaster-users@livingston.com]On Behalf Of Karl
Denninger
Sent: Monday, July 20, 1998 5:55 PM
To: Mikael Hugo
Cc: 'portmaster-users-digest@livingston.com'
Subject: Re: (PM) Clarification of POW

Well, the real issue here is screwing the pooch as happened in b17.

Folks, this happens. But its exacerbated by "don't be like vendor <X>" (who
we all know) attitudes which lead to extended internal testing regimes which
*cannot* and *do not* mimic real-world use.

My suggestion? If it compiles, loads, and the Ethernet comes up let me have
it. If it sucks I'll tell you within hours. Then add a line to the README
file for each report of "suckiness" for that release, and label the whole
thing CAVAET EMPTOR.

If someone calls support with a problem that is in the README, direct them
to the README. That's it. If they call with a NEW problem, add it to the
README.

Now, engineering takes that README (and its cavaeats) and fixes them. AS
THEY FIX THEM, they compile, load, and verify the Ethernet works - and post
the new file.

Iterate until the README exception list is deemed acceptable, then call THAT
a Beta. If THAT passes wider use, relabel it and call it a RELEASE.

This will produce working code at least twice as fast as we are getting
right now. Absent STRUCTURED software and testing plans, which are clearly
absent in the Livingston (and virtually everyone else's) products due to
their heritage, this is the best you can do. And no, I'm NOT bitching about
the lack of formal design criteria in the code; we all know how it came to
be written originally, and we all bought off on the Livingston story when we
went with their equipment (well, those of us who talked at length with them
first anyway, or know their story through the industry).

The point here is to get working code through an iterative process that is
the only one which CAN validate what you build in a reasonable timeframe,
and with a reasonable expectation that you are getting the most serious
bugs fixed BEFORE you claim something is "FCS".

Doing this requires putting away the ego that says "we can't release code
that is broken". The fact is, right now Livingston is releasing code (even
beta code) that is broken, and they always will be so long as unknown
interactions and unknown code paths exist.

The only effective control against that is to get as many people in as many
diverse environments involved as early as possible so you don't WASTE
man-weeks testing code that is broken badly enough to be worthless to
huge segments of the user population.

That requires an open code foundary, to coin a phrase.

--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly / All Lines
K56Flex/DOV
			     | NEW! Corporate ISDN Prices dropped by up to 50%!
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL
ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no
cost

On Mon, Jul 20, 1998 at 11:40:49PM +0200, Mikael Hugo wrote: > >|| I have over the past weeks grown REALLY tired of the discussions > >|| regarding non working betas, that doesent lead anywhere. > > > >while i agree with you as well, and the beta specific newsgroup would > be > >nice, there DOES need to be discussion about the problems. As that's > how > >you find what's working and what's not. > > Just to clarify (Have gotten numerous reponses like this one) - > > I am not against betadiscussions or uninterested in beta discussions. > > I am tired of betadiscussions that is not constructive and leading to > progress - Whining, complaining is the worst of it, but also discussing > broken stuff that the list several times has agreed that it can only be > fixed with new software. > > It would be easier to decide wether you want to read the betadiscussion > or not if the list is split into beta and production. > > Best regards > > Mikael Hugo > > dataphone communication networks > http://www.dataphone.net > > tel 08 - 566 106 00 / 031 - 758 06 00 / 040 - 698 06 00 > fax 08 - 566 106 01 / 031 - 758 06 01 / 040 - 698 06 01 > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe portmaster-users' in the body of the message. > Searchable list archive: <URL:http://www.livingston.com/Tech/archive/> - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>

- To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>