Subject: Re: rocket science
From: Robin 'Roblimo' Miller <>
Date: Sun, 27 Feb 2005 06:07:15 -0500

Tom Lord wrote:

>   From: "Robin 'Roblimo' Miller" <>
>   In other words, this vaunted software project is the antithesis of 
>   private enterprise, freedom, and corporate efficiency in almost every 
>   way, right down to stifling creativity. It has more in common with 
>   Social Security than with the Mplayer project.
>Wow.  How you got from there to that.... amazing.

Not at all amazing if you've spent a significant part of your adult life 
hanging out with people who work at NASA, Lockheed Martin, Social 
Security, and other government agencies -- and have also spent time 
monitoring development email lists for FOSS projects AND work (or know 
people who work) for a profit-driven small- or medium-sized company.

 From the article:


What's going on here is the kind of nuts-and-bolts work that defines the 
drive for group perfection -- a drive that is aggressively intolerant of 
ego-driven hotshots. In the shuttle group's culture, there are no 
superstar programmers. The whole approach to developing software is 
intentionally designed not to rely on any particular person.

And the culture is equally intolerant of creativity, the individual 
coding flourishes and styles that are the signature of the all-night 
software world. "People ask, doesn't this process stifle creativity? You 
have to do exactly what the manual says, and you've got someone looking 
over your shoulder," says Keller. "The answer is, yes, the process does 
stifle creativity."


I was in the Army, and found the cliche line about how there's a "right 
way, a wrong way, and the Army way" to do something to be true. I 
learned the Army way to do things ranging from shining shoes to 
diagnosing complex electronic equipment to maintaining a constant rate 
of fire with an M-60 machine gun. The Army is huge and sloppy, so you 
see a little creativity creep its way in from time to time, but woe unto 
you if you deviate from "the book" and fail. However, if you succeed 
with your creative change -- and document it correctly -- there's a good 
chance that your change will end up in the next version of "the book" 
(probably a Field Manual) that covers that action. You might even get an 
award for doing good work if your changes are accepted. (I got a few 
myself, including one that had significant cash attached to it.) But 
acceptance of change and innovation is not as common as blind adherence 
to procedure. It is safer to "go along to get along" than to Question 
Authority in the military -- and in most other large government operations.

A long-running complaint about NASA's computer systems is that its 
rigid, time-consuming acceptance procedures keep its hardware and 
software generations behind what's available in the consumer 
marketplace. This complaint applies just as much to Lockheed Martin and 
other large NASA contractors as to NASA itself. It's a case of Debian 
stable being slow to accept new packages carried to the nth degree, you 
might say. You give up innovation in exchange for reliability.

I am not passing judgement on one way of doing things over another.