Signal-to-noise in sci.space.* (was Any legal basis to take Maxson down?)

Doug... said:
Yep, there are good reasons for some of that "bureaucratic bs."

One of the genuine challenges of engineering management is to impose
the correct bureaucratic process. Just adding a new layer of paperwork
every time a mistake isn't caught can quickly stifle progress.


And in
my experience, programmers and engineers who insist that documentation
requirements are unecessary because *they* already know the details of
their own systems are usually either a) lazy or b) trying to maintain the
ego-boosting position of being the only person who understands something
no one else understands. Both situations often result in disaster.

I'll add c) they lack the engineering maturity to realize the
importance of the documentation. I've seen a project die or nearly so
when one or two key people left the team. The engineering talent is
usually replaceable, but the in-depth knowledge of how the software
functions was limited to those one or two minds.

The current flavor of the month in commercial software development is
eXtreme Programming. XP is a counter-reaction to too much process and
paperwork. The focus is on building a small, lightweight, agile team
that can respond to changes quickly and effectively. Because they
respond so well to changes (the XP proponents claim), there is no need
for excessive written documentation, nor time consuming reviews of
completed programs. The XP philosophy is "the tests all run without
error, so the software must be right. I'm watching XP with fascination
and dread. It is a tool that has some value in some circumstances, but
XP is being used on tasks that are well beyond XP's capabilities.
--
Kevin Willoughby lid

We'd spend the remaining time trying to fix the engine.
-- Neil Armstrong

On Sat, 16 Aug 2003, Jorge R. Frank wrote:
There is no evidence to support this view. I am talking about redirecting
threads from s.s.shuttle - and *only* s.s.shuttle - to s.s.moderated. The
moderators prune the noise, leaving only the signal. The end result is that
the traffic on s.s.moderated will equal the sum of 1) its current traffic,
plus 2) the traffic on s.s.shuttle, minus 3) the noise on s.s.shuttle, plus
4) the signal from any newbies that were allegedly previously intimidated
from posting on s.s.shuttle. In my opinion, there is *no way in hell* that
4) is greater than 3), therefore the total traffic *will* go down.
Undoubtedly the signal-to-noise will go up. *Way* up.

On the same topic...

I would suggest that people be vocal and clear about redirecting
the threads that are of interest to s.s.m. That will highlight
to the newbies what is going on, rather than have them get
confused by seemingly random changes in the newsgroups line.

--

Leach

Leach wrote in
:

On Sat, 16 Aug 2003, Jorge R. Frank wrote:
There is no evidence to support this view. I am talking about
redirecting threads from s.s.shuttle - and *only* s.s.shuttle - to
s.s.moderated. The moderators prune the noise, leaving only the
signal. The end result is that the traffic on s.s.moderated will
equal the sum of 1) its current traffic, plus 2) the traffic on
s.s.shuttle, minus 3) the noise on s.s.shuttle, plus 4) the signal
from any newbies that were allegedly previously intimidated from
posting on s.s.shuttle. In my opinion, there is *no way in hell* that
4) is greater than 3), therefore the total traffic *will* go down.
Undoubtedly the signal-to-noise will go up. *Way* up.

On the same topic...

I would suggest that people be vocal and clear about redirecting
the threads that are of interest to s.s.m. That will highlight
to the newbies what is going on, rather than have them get
confused by seemingly random changes in the newsgroups line.

I agree completely. Along the same line, I don't plan on redirecting
threads that are crossposted into sci.space.shuttle from people who are
obviously posting from other groups, like the HST/JWST thread I replied to
today. There is a good chance, in these cases, that the poster isn't
subscribed to s.s.m.


--
JRF

Reply-to address spam-proofed - to reply by E-mail,
check "Organization" (I am not assimilated) and
think one step ahead of IBM.

"Cameron Dorrough" wrote in message
...

Thanks, Rich - that does clear a few things up. I've been lurking around
s.s.t the most, due to my interest in things technical, and very often
posts
can take more than 24hrs to reach me.

The issue isn't just *my* posts, but *any* posts to the NG. My ISP has
been
having a few hassles so that may be it - I think the timezone issue might
be
another one (the moderators being asleep sometimes when people over here
post.)

It's 9:40am here - I'll see how long this takes to get there.. ;-)

It just appeared on my news server - it's 12.50pm local time. ..but it
hasn't appeared on the Google Groups yet (work that out!).

Hmmm. 3 hours 10 minutes and some seconds. Must be a record! :-(

Cameron:-)

Kevin Willoughby wrote:

James Summers said:
In some ways, it was easier then. We had a lot less bureaucratic bs to put
up with.

In theory, the purpose of the bureaucracy is to prevent important
details from slipping through the cracks. How did you keep with rate of
change in requirements during Apollo?

A bureaucracy kept book on all that.

But keep in mind the two faces a bureaucracy. One that is nominally
on your side in pursuit of a common goal is a good thing from the
worm's eye view. One that insists on schedules, budgets, performance,
etc... is not.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.

The current flavor of the month in commercial software development is
eXtreme Programming. XP is a counter-reaction to too much process and
paperwork.

As someone who has done commercial software development (with and
without XP), I would say that XP has much more process than what is
typical in commercial software development. There are lots of people
for whom XP is their first exposure to unit tests, acceptance tests,
release planning, and the like.

Of course there are people for whom "XP" just means "throw out what
little paperwork we have and go back to cowboy coding" but that's
people finding what they want to find, not people actually reading and
applying the XP books and websites.

It's in my reading queue to finish going through the mishap report for
Apollo 13 and look at the root cause for this. There would have been
a parts stress analysis done. Was there an error in it? Was it not
done? Did it not get updated for a change? Or was part of it not
done since it hooked up to GSE?

It's been a while since I read the mishap report, but basically the
voltage got changed from 28V to 65V (or whatever the exact numbers
were) and not everything got updated accordingly. It didn't show up
on the ground because it was a "sometimes fail" kind of deal (I
believe). But if you do get around to reading the mishap report
(which I believe is on-line, for anyone interested), please do offer a
more detailed description of the various tests/analyses and where
things got missed.

The mishap report urged more attention to change control and my
impression is that this is one of the sources of much of the paperwork
that we see today (with the various good and bad consequences
thereof).

Jim Kingdon said:
The current flavor of the month in commercial software development is
eXtreme Programming. XP is a counter-reaction to too much process and
paperwork.

As someone who has done commercial software development (with and
without XP),

Likewise.


I would say that XP has much more process than what is
typical in commercial software development.

No. XP eschews the concepts of Product Requirements (telling stories
just isn't the same), pretends you don't have to design something
before building it (note the heavy emphasis on refactoring), assumes
that it is better to read 50 pages of code than one page of prose (note
the XP philosophy of minimum documentation), and misunderstands the
distinction between Quality Assurance and testing (unit tests are
necessary, but far from sufficient).

If you read what Kent Beck has written about his creation of XP, it is
clear that it was a counter-reaction to a process-excessive
environment. He went from one extreme to the other. Neither extreme is
desirable.

ObSSM: On the day the CAIB released their report, I read the section of
Secret of Apollo that did a compare&contrast on the Ranger and Mariner
programs. Oversimplifying the author's views a bit, here we had two
series of roughly similarly complex spacecraft, built and flown by the
same organization (JPL), with very different results. Ranger was a
disastrous failure -- six flights(*), each and every one a complete
failure. Mariner was a success. The difference? Marriner had a
comprehensive process, including serious change-control and
configuration-management, with strict attention to be sure that "as
built" exactly matched "as designed", and the design was based on
complete specifications. In today's vocabulary, Mariner was process
heavy and Ranger was XP.


There are lots of people
for whom XP is their first exposure to unit tests, acceptance tests,
release planning, and the like.

Sure, there are newbies in any field. Hey, I was one myself, long long
ago. But the fact that it introduces new concepts to newbies isn't the
same thing as saying that XP has more process than typical commercial
environments.




* There were follow up Rangers that were successful. Ironically, if it
hadn't been for the success of Mariner, JPL might have been shut down
before Ranger 7 flew.
--
Kevin Willoughby oSpam

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins

rk said:
Jim Kingdon wrote:
It's been a while since I read the mishap report, but basically
the voltage got changed from 28V to 65V (or whatever the exact
numbers were) and not everything got updated accordingly.

From what I recall, those numbers are about right and it was for the
non-flight interface on the tank; the flight interfaces stayed at
28V, which is a semi-standard spacecraft voltage.

Many years ago, I built a commercial DataBase Management System. That
forced me to learn a bit about this history of DBMS's. The first
significant commercial DBMS was IBM's IMS. Somewhere or other, I read
that IBM acquired IMS from North American, who created it to keep track
of the huge number of changes that they knew would be serious issue in
building the Apollo CSM. The system worked pretty well, since the only
non-trivial configuration management problem in the CSM that I can
recall is the Apollo 13 oxygen tank.


The mishap report urged more attention to change control and my
impression is that this is one of the sources of much of the
paperwork that we see today (with the various good and bad
consequences thereof).

As I've noted elsewhere, I'm following the successes and failures of
eXtreme Programming with amusement and interest. XP really tries to
minimize paperwork to its absolute minimum. To his credit, XP creator
Kent Beck seems to understand that this works for, and only for,
relatively small projects. Once you get a project team that can't all
have lunch around the same table, you *can't* rely on informal chats,
you have to adopt a more formal approach. Apollo was a hugh project
with many subtle inrelationships among its components, so it required a
lot of paperwork.


Actually that sort of thing preceeded Apollo. It's a major theme in
_The Secret of Apollo_ which I'm now reading

That major theme is one of the issues I have with the book.
Configuration management *wasn't* invented to build rockets. Johnson
makes an eloquent case that configuration management is required for
systems as complex as an ICBM, much less Apollo. (I mentioned his
Ranger / Mariner case-study elsewhere. I should add his Corporal /
Sergeant case-study further emphasizes this need.) But the claim that
it was invented for big rockets just doesn't match my understanding of
the history of technology. As a kid, I had to listen to my father
explain the differences between the P-51B and P-51D, so clearly North
American was doing some kind of configuration management during WW-II.
I suspect (but can't demonstrate) the concept goes back at least to the
introduction of mass production / standardized parts.


-- and this book [...] is rapidly becoming one of my best.

Mine, too. As a kid, I wanted to be an astronaut when I grew up. I've
read a lot of books written (at least nominally) by astronauts. As I
became more interested in engineering, I became fascinated by the
hardware of Gemini and Apollo, which is described in many books. As I
tried (unsuccessfully) to be an engineering manager, I wondered about
the management of Apollo. *That* topic is woefully underrepresented in
the literature -- Murray & Cox is great for what it is, but doesn't
describe the management processes as seen by a manager. Secrets is
teaching me a lot.

Last weekend, my girlfriend dropped by and noticed the books on my
living room table. Of that dozen books, two are space-related. She
looked at Secrets of Apollo and commented that it was an expensive
book. She picked up Collin's Carrying the Fire, and noted it cost less
than half as much. I'm only about 1/3 of the way through the book, but
I've gotten more than my money's worth of insight from it.
--
Kevin Willoughby oSpam

Imagine that, a FROG ON-OFF switch, hardly the work
for test pilots. -- Mike Collins