Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: "Practices and Principles" to death

by dragonchild (Archbishop)
on Feb 29, 2008 at 14:56 UTC ( [id://671178]=note: print w/replies, xml ) Need Help??


in reply to "Practices and Principles" to death

A few thoughts:
  • Shit happens. There is absolutely no way to prevent all badnesses, period. That's why we have insurance.
  • Failures sometimes happen through lack of enforcement, not lack of procedures.
  • The procedure that requires a new procedure for every failure is, itself, a failure.
  • If the loss of a single satellite is such a major disaster, then maybe making satellites should be made cheaper. I personally like working in industries where a 1-5% failure rate is not only expected, but hoped for.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re: "Practices and Principles" to death

Replies are listed 'Best First'.
Re^2: "Practices and Principles" to death
by moritz (Cardinal) on Feb 29, 2008 at 15:06 UTC
    If the loss of a single satellite is such a major disaster, then maybe making satellites should be made cheaper.

    How? You can't scale that very well.

    When you sell an electronic device, you can drop the cost by selling 100x more items.

    If you do that with satellits, and put them in orbit, the leftovers of the old satellites will bombard and destroy your new ones.

    And even if making a satellite can be made cheaper, it still costs $huge_amount to put them in orbit.

      (Note: you're entering into an area that I have a lot of interest in and have thought about for years, so please be prepared to back yourself up.)

      You're presenting very real issues. Sounds like there's a number of excellent industries waiting to spring up. For example, garbage-collecting dead satellites and other debris. No, I have no idea how this would be done. Sounds like the perfect use for a field of some sort on a drone sweeping around the earth in an orbit that traverses the entire spherical shell of a given height. If all known satellites are in a database somewhere (another business opportunity similar to credit bureaus), there isn't a problem. If finding these satellites is a problem, that's another business opportunity. In other words, the cost of managing of all these items can easily be handled by entrepreneurs in the free market.

      Now for lift costs. This is an interesting problem because it makes a lot of assumptions that may not be valid for more than a few years. So, let's talk about this.

      Lets look first at what cannot be changed - the amount of energy it takes to raise the potential energy of a certain mass such that it is in LEO. That energy needs to be applied to the mass in such a way that it raises the potential energy without damaging the mass. The way that has been done thus far has been to use rockets which are extremely inefficient. And, they're more inefficient the closer to the ground you are. If we could only start our rocket halfway up, we would cut our energy needs by 75% (Inverse Square Law). There are easily a dozen solutions here, but they all have a rather high capital cost. Amortizing that cost is the key.

      Now, why do we have to build satellites on Earth? Why can't we build them in orbit? If we could do so, we wouldn't have to make them so sturdy (to survive liftoff), which means they would require significantly less material. Since you'd have a foundry in orbit, you probably have power generation in orbit. Why not share that power generation capacity through beaming (a proven, if unused, technology)? Now, all you need is the actual purpose of the satellite. A lot easier to work with.

      Furthermore, why do we have to have people in orbit to build these satellites? The cost of the ISS would drop by about 90% if it didn't need people on it. I'm not advocating a human-free space exploration program. In fact, I'm not advocating a space exploration program at all. I'm coming from the perspective of a space occupation program.

      Basically, you find that the marginal cost of a given product (such as a satellite) drops dramatically if the proper infrastructure is in place. Very much like Perl when it comes to programming. I know you've discussed how productive you are in Perl vs. other languages in the past. That's due to the infrastructure you have. That infrastructure cost over 1_000_000 manyears (counting CPAN), but has been amortized into saving that many man-years every year. That's all that's needed in space, too.


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        Right now something like 30% of the space junk up there comes from one Chinese satellite getting into a collision. We have at the moment no workable ideas for how to get that debris down other than wait a few centuries. And since it is traveling over 10,000 miles per hour, blasting it into smithereens just results in too much sand to track, but even a single grain of the stuff is potentially lethal.

        Before I'd support your approach, I'd want to see answers to how we plan to get rid of the debris from one collision. After that I'd like to see a plan to handle the potential problems from a careless company cutting corners and having a few more space accidents. And before you wave the free market magic wand, with known techniques it takes a lot of work to get a single flying screw down. How do we supply a profit motive to reward private enterprise for that work?

        It is always easy to say, "Oh the market will take care of it." But markets don't work very well for certain kinds of problems, and dealing with litter in near space seems to be one of those problems.

        And for the record I'd love to see a solution to it. Because until we can come up with a solution, I don't think we're going to successfully colonize near space. (The ultimate solution may be to be very, very careful with near space and instead leapfrog human colonization out of low Earth orbit.)

        Oh, my! Don't get me started...so much of what you wrote is, in my experince, so very true. That is most impressive from one not 'in the business.'

        As you've probably already recognized...I tend to write prolifically and I suspect the rest of the Monks would get both irrateted and bored with all the satellite talk.

        So I'll hold my enthusiasm and just say that I agree with so much of what you said and I thank you for it. It gave me a lot to think about and to cogitate on...and grow from.

        I would also like to note how very cleverly and kindly you brought the discussion back to Perl...which I'm sure the rest of the Monastery appreciates very much.

        Thanks, dragonchild.

        ack Albuquerque, NM
Re^2: "Practices and Principles" to death
by ack (Deacon) on Mar 01, 2008 at 03:37 UTC

    You are, IMO, a very insightful and wise monk!

    You just made my day...

    And may have just given me a couple of new "Axioms of Systems Engineering" which I have been working on from my 30 years in the business...if you give me permission...and I promise to always recognize you as the author.

    On the other hand, maybe they're too much for the mere mortals that I work with to handle. ;-)

    ack Albuquerque, NM

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://671178]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2024-04-26 00:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found