JavaScript is disabled
Our website requires JavaScript to function properly. For a better experience, please enable JavaScript in your browser settings before proceeding.
I am sure many of us are on a list, especially those of us who own firearms.

Now where we are on that list with respect to the gov's interest in us... probably pretty low for most of us.

OTOH, if the gov ever gets it into their heads to start randomly confiscating firearms...
Hell yes, have a permit, buy guns, buy ammo. No doubt some "list" has Wife and I on it. Again though how many millions of us? That so many people seem to think they are so important that some gov agency is tracking them? :confused:
They can't seem to keep up with most of the criminal scum. So if they are tracking they do it like so many things the gov does. :s0140:
 

Summary: launch was ok. they caught the booster when it landed. but they lost contact with the ship after the engines on the second stage seemed to fail just before SECO? No report on what happened beyond that.
 

Summary: launch was ok. they caught the booster when it landed. but they lost contact with the ship after the engines on the second stage seemed to fail just before SECO? No report on what happened beyond that.
Still way ahead of Blue Origin and their New Glenn, "So You're Telling Me There's A Chance" named booster....
 
Space X and Blue Origin are using completely different development paradigms.

SX is using the Build-Test-Refine paradigm where they destroy a bunch of prototypes and solve problems as they find them. This is fairly unique to the aviation industry and is producing some astonishing results, as well as some spectacular (but expected) failures.

BO is using the more cautious Engineered Certainty paradigm (under several different names like AGILE and 3E. I do not know which one they are using specifically, or if they are using a home-brew version, but they are all basically the same concept). Their first launch is expected to be successful because they have done all the testing piecemeal before total integration. But this also means that their design is far more iterative than revolutionary, because it is hard to exhaustively test partial designs that you have zero prior data on.

Both methods have merit, but SX will be the one most likely to produce a truly revolutionary paradigm shift in the space industry (just like they did with Falcon). I look forward to the access both platforms will give us to space.
 
Agile - the kind with "sprints" and short iterative cycle development - often used in s/w dev, is more akin to what SpaceX does.

I don't know what other spacecraft/rocket design/development orgs use as a dev strategy/practice, but having used Agile myself at several different orgs in my s/w dev career, from what I have read it sounds like that is what SpaceX is using.

I've also been at orgs where the dev teams would go "dark" for months on end (e.g., 6-12 months) and by the time they had even an alpha release, it often was not what the org or the customer wanted, and/or the market changed.

Plus with short (less than a month) iterations, you show that you are making progress (very important as it helps you keep your job), and you can adjust (be agile) to a changing environment (the whims of management and/or the customer/user).
 
Agile - the kind with "sprints" and short iterative cycle development - often used in s/w dev, is more akin to what SpaceX does.

I don't know what other spacecraft/rocket design/development orgs use as a dev strategy/practice, but having used Agile myself at several different orgs in my s/w dev career, from what I have read it sounds like that is what SpaceX is using.

I've also been at orgs where the dev teams would go "dark" for months on end (e.g., 6-12 months) and by the time they had even an alpha release, it often was not what the org or the customer wanted, and/or the market changed.

Plus with short (less than a month) iterations, you show that you are making progress (very important as it helps you keep your job), and you can adjust (be agile) to a changing environment (the whims of management and/or the customer/user).
I suppose that is arguable, but in the context I was envisioning the AGILE process would mean iterative unit testing on the individual components prior to integration, not iterative testing on the entire stack at once like SX does. BO may or may not be using AGILE on a component/sup-component level, but it is certainly not using it on the entire stack.
 
I suppose that is arguable, but in the context I was envisioning the AGILE process would mean iterative unit testing on the individual components prior to integration, not iterative testing on the entire stack at once like SX does. BO may or may not be using AGILE on a component/sup-component level, but it is certainly not using it on the entire stack.
Oh they do unit testing, but you need to do integration testing too, and that can (and often does) happen at or near the end of a sprint when a build is released to testing.

From what I heard about SX's processes, they do a LOT of unit testing prior to a launch.

As an aside, when I went to interview for the job at DTNA, I asked if they did unit testing and they said yes.

I should have asked what they considered unit testing to be - they did not have a clue; they thought it was integration testing; testing each feature in a build. It turns out that their software was such a mess and so tightly coupled, that no one given unit could be separated to test it alone. I tried and tried and just could not decouple anything.

Eventually, I took over as lead for the team and mandated that any new code would be unit tested. One of the SMEs thought it was a waste of time. It was a real struggle to get the mind set changed - I don't think that SME ever changed his mind on the issue.
 
Last Edited:
Oh they do unit testing, but you need to do integration testing too, and that can (and often does) happen at or near the end of a sprint when a build is released to testing.

From what I heard about SX's processes, they do a LOT of unit testing prior to a launch.

As an aside, when I went to interview for the job at DTNA, I asked if they did unit testing and they said yes.

I should have asked what they considered unit testing to be - they did not have a clue; they thought it was integration testing; testing each feature in a build. It turns out that their software was such a mess and so tightly coupled, that no one given unit could be separated to test it alone. I tried and tried and just could not decouple anything.

Eventually, I took over as lead for the team and mandated that any new code would be unit tested. One of the SMEs thought it was a waste of time. It was a real struggle to get the mind set changed - I don't think that SME ever changed his mind on the issue.
Oh I get what you are saying, I think we are just talking about different scales. For all the individual component testing SX does they still build a whole prototype and send it, knowing full well there will be failures. They just want to see what breaks on the full stack so they can fix it as a whole, rather than do more comprehensive testing to failure on the ground (unit testing, discrete integration testing, etc.)

BO, on the other hand, does do all that testing on the ground, does do their integration testing in much more discrete steps, and generally builds for success on the first launch. This is how most of the aviation industry works; by the time they have a public launch/flight they are pretty confident in success and do not expect failure. I know they were disappointed that they did not land the booster on their first attempt, because that was the expectation they set for themselves.

Now the perception is that SX's methodology is messier but faster, allowing for rapid iteration, data gathering on completely novel systems (which like I said are much harder to do physical unit testing on because you are not always sure what you need to be looking for) and may actually be cheaper despite the spectacular (and expected) failures, but there is also the problem of confidence building with that method, because eventually you have to convince your customers that this launch is no longer a prototype and is indeed a finished and reliable product.

This is another place SX has an edge over the competition, and why I think there is a perception that they can get away with the public displays of dirty engineering; they have their own payloads to put into orbit so they do not have to convince customers to try out the first "production launches." They can put up a dozen StarLink payloads to prove that their stack it ready for prime time and only take other customers payloads after they have a solid and proven flight record under their belt.

BO does not have an internal program for payloads* and is relying 100% on external customers to pay for launches. To me this means they need to display a much higher confidence level in reliability as they cannot afford the perceptions that maybe some of their first payload launches are a little more prototype than production. If their first launches are not all successful they will have a much harder time justifying a payload on the next launch, which either means more expensive dummy payloads or finding someone willing to risk a mission loss for a discounted price.

*Yes I know Amazon has plans for their own data constellation. But it is not ready to fill the demand New Glen rockets can accommodate short term. The first dozen payloads they are going to send up will still need to be external customers who trust the rocket can do the mission.
 

Upcoming Events

Roseburg Rod and Gun Club Gun Show
  • Roseburg, OR
Redmond Gun Show
  • Redmond, OR

New Classified Ads

Back Top