9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jack Johnson <fragment@nas.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] a bug in freopen
Date: Thu,  8 Aug 2002 10:34:59 -0700	[thread overview]
Message-ID: <3D52ABC3.8020203@nas.com> (raw)
In-Reply-To: <3D527DE2.B38A88DE@null.net>

Douglas A. Gwyn wrote:
> Jack Johnson wrote:
>>If only Microsoft would do that.
> ? In which direction do you think they err?  Too much testing or
> too little?

Sorry, Douglas (and everyone).  It was a bad pun run amok.

But, giving it some pre-coffee thought, they construct solutions to
perceived problems, which is a great business model.  I feel sometimes a
problem is not best solved by adding a new solution but by taking away
an old problem.  Maybe not the best way to run a software development
firm, but then again, I don't have that worry.

So, in that respect, I think they probably do more than adequate testing
  to ensure their product solves the problem they intended to fix (and
thus I damn their effort with faint praise).

When going through their recruitment process, I was told that (in the
group for which I was interviewing), the standard procedure was to spend
  24-36 months developing a new release, then releasing a service pack
roughly once every 6 months.  After 2-3 service packs, they'd determine
the new features they wanted in the next release, and go through the
cycle again. The service packs are released to fix bugs and add features
as requested by their largest vendors, and working down from there.

I was appalled at the idea that the working model was based on fixing
bugs after the release, that it was the expected norm, and that new
releases were not based on making the product qualitiatively (or hell,
quantitatively) better but firmly on adding new features, for which any
new bugs (that got through the testing cycle) would be worked out at a
later date.  Several times.

Now, I understand all software has bugs, and what a nightmare it must be
to manage 20,000 developers and n million lines of code, but if you want
an edict from Bill Gates, why not "Just One Service Pack"?  If the
standard procedure is to allow some bugs to be fixed post-production, it
seems no wonder that they've had certain difficulties with security.

----

Sorry for the rant.  The bad pun may have been better.

-Jack

P.S.
For the curious, I chose not to write VB script for a living, and my
checkbook resents it wholeheartedly.



  reply	other threads:[~2002-08-08 17:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-06  2:38 presotto
2002-08-07 16:52 ` Jack Johnson
2002-08-08 15:39   ` Douglas A. Gwyn
2002-08-08 17:34     ` Jack Johnson [this message]
2002-08-09  8:57       ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2002-08-09 12:36 rob pike, esq.
2002-08-09 17:18 ` Douglas A. Gwyn
2002-08-10 16:14 ` Jim Choate
2002-08-05 12:29 presotto
2002-08-05  9:55 Saroj Mahapatra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D52ABC3.8020203@nas.com \
    --to=fragment@nas.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).