SpaceDev gets Agile Development

More Agile Space Development sightings:

In his interview with MSNBC, SpaceDev CEO Jim Benson says:

So right now, SpaceDev is more on the hardware side of developing the enabling technology, in terms of extremely high-performance, low-cost satellites. We've got a project right now at the Air Force Research Laboratory, that we call SSBT, small satellite bus technology. The whole purpose of this $750,000 program is to turn us loose in defining modular, plug-and-play, hardware- and software-oriented microsatellite buses. We are not only doing that, we are actually implementing it in our three Missile Defense Agency satellites.

These are truly plug and play. The subsystems will be interconnected with industry-standard interfaces Ethernet, USB and RS422, take your choice. Guess what operating system we're running under? Linux. It's free! We're writing object-oriented software modules like device drivers.

Also in talking about his Orbitial Dream Chaser craft:

So then we looked around for another existing designed vehicle with the right shape. We haven't announced which one or ones fit those criteria, but we did find something. We came up with what we think is a very simple and practical approach that requires no new technologies whatsoever. And that’s a big problem with most of these systems, is that they do require new technology. That becomes very expensive and very risky. Schedules tend to slip when you’re developing a new technology for a specific application. So we were very careful to design SpaceDev Dream Chaser around existing technology, and we simply scaled up our rocket motors to a larger size.

Now that is Agile. Go Jim!

There's some good news and some bad news...

NASA has finally settled on the inline shuttle derived HLV. Damn.

But on a lighter note, Virgin Galactic announced the development of SpaceShip 3, a suborbital version.

Well you gotta take the good with the bad, right?

--Update Aug 23, 2005 9:41am--

According to Nasawatch.com,

It would seem that multiple offices in the executive branch simply do not agree on key elements of what Griffin wants to do - and have serious problems with certain aspects - finances being the most important point of disagreement. Stay tuned.

Let's keep our fingers crossed for a more modular solution...

Agile at work in Space

This is agile at work. Using existing UDP/IP or SMTP (store and download like email) for the communications protocols for space missions. Duh! Why create a whole new comm networks for each mission when you can by a TCP/IP stack on any cellphone.

This is my agile argument for me:

After reinventing this wheel at least four times by the early 1990s, Hogie came to understand the power of the Internet Protocol. IP is the lingua franca for data communications. It's not just the way bits are packaged for transmission on the Internet but also how they are routed from machine to machine. As happens all the time on the Internet, two computer systems using wildly different hardware a Hewlett-Packard PDA and an IBM mainframe, say can pass the data back and forth, so long as they both speak IP.

And this should tell you something. With littlforethoughtht and now extra programming:

To prove how powerful this concept of using IP in space could be, the Goddard team set up a log-in accounta user name and a password for some colleagues at the Marshall Space Flight Center, in Huntsville, Ala., so they, too, could access the ill-fated shuttle's computer. Without a standard TCP/IP connection, Marshall might have had to commission someone like Hogie to write the software that would make the connections to give access to its engineers. But with TCP/IP, accessing the shuttle was as easy as using an AOL account. Once logged on, technicians could upload or download files, check the logs to see how the onboard server was running, or do anything else the staff at Goddard could do.

This is what agile (and common sense) can do for you.

Remembereber, the best solution is sometimes the hardest, but it is never the stupidest. (you can quote me on that :)

Thanks to Nasawatch.com and Keith Cowling for pointing out this article...

Happy Birthday to Me!

To anyone who is interested, today is my 30th birthday. So I will have chocolate cake with lemon icing, get a Ben Bova novel from my wife, and keep working on my article on Agile space development.

Agile Space Mission Development Part 1 - Quality Infrastructure

After my last post on Agile Space, I got to thinking, 'This could be more closely related that I originally thought" So, if my readers would indulge me, I would like to explore the usefulness of Agile Development in space. Comments are encouraged and appreciated.

In part one we are going to explore some of the tenets of what being Agile means. In the OO coding world, quality code has a number of attributes.

• Strong cohesion
• Loose Coupling
• Non-redundant
• Readable
• Correct

Great. So how does this affect space development. Well I think correct goes without saying. You mission has to be correct. Trajectories, thrust, weight, distance all has to be right. So move on to the less obvious mappings.

Cohesion is defined as how “closely the operations in a routine are related.”(1) Well, lets paraphrase that to “how closely the operations of a single module in a mission are related.” We will defer defining what is meant by a module until later. So clearly a module of a Lunar mission who's purpose was to send men into LEO would have strong cohesion. As oppose to one who's purpose was to transport people, cargo, and be a floating laboratory would have weak cohesion (djs: heard of a system like that :) . Based on my experience with software systems, Strong cohesion almost always makes software more flexible, as it is a more atomic unit. Just as a CXV type vehicle could be used in many types of missions, from ISS transport to docking with a deep space colony transport. So, I conclude that strong cohesion is useful to both software and space development.

Okay, what about loose coupling. coupling is defined as “the strength of a connection between two routines.” or put more simply, “Coupling describes how strongly a routine is related to other routines.” (1) So, to paraphrase, “the strength of a connection between two modules.” Hmm, so we want internal integrity with flexible relations between modules. Well that sounds good, but what does it mean for space.

If a module, such as an orbiting refuel tank, requires a module it interfaces with, such as a Lunar transport system, to have a certain way it stores the fuel it has tight coupling (bad). It means it would place detailed requirements of how any module who need to be refueled processed the fuel, thus limiting innovation. What we want is two modules who interface and don't “care” what the other module does with the “thing” that is transferred. That is loose coupling and it allows a module to be used with many different modules. Everyone just has to understand the interface. So again, I conclude that loose coupling is useful for both software and space development.

Non-redundancy may seem like a no brainier, but let's example it like good philosophers. Redundancy means more that one routine performing the same function. So in our Agile space world, more than one module performing the same function. That is a little harder, because we want some redundancy. We want more than one company offering launch services. We want more than one way to get to the moon. It's cheaper that way. But within a specific mission, what you don't want is a requirement for the modules to interface with different modules that do the same thing. If you have a refueling tank in LEO, why have a different one in Lunar orbit. If you can reuse a module, use it. This is the heart of Agile space development.

Let me know what you think so far. Part 2 coming later...

---------------------------------------------
1. McConnell, S., Code Complete: A Practical Handbook of Software Construction, Redmon: Microsoft Press, 1993.

SpaceDev continues to make money...

In case you missed it, SpaceDev just posted there second consecutive quarter of profits.

According to there Form 10-QSB filed August 15, 2005, SpaceDev make a net income of $110,938 or 5.8% margin. That makes $212,962 for the year.

Just FYI stock is spdv.ob and is sitting at around $1.50

Haloscan commenting and trackback have been added to this blog.

Agile Space Mission Development

Sorry I haven't been blogging for a while. No, I am not dead or in jail or anything bad. I got promoted and we hired a lot of new guys I had to bring up to speed this month, so what are you going to do. On to the subject at hand....

Jonathan Goff on his blog Silenian Boondocks, has a new post out on how NASA could do a moon mission in an open architecture, commercially supported fashion. As a quasi-libertarian (at least economically) I agree with his ideas. After reading his post, though, I see another reason for the light-launch, re-fuel in orbit, option.


Let me discuss software development methodologies for a moment. (All non-software engineering geeks bear with me). In the last decade or two, object-oriented development has brought for many ideas on how to create good software systems. First with Design Patterns based on Christopher Alexdander's brilliant "A Timeless Way of Building" which first proposed patterns in architecture. The "Gang of Four" as they are so affectionately referred to took that idea and wrote the foundation of OOD in the last decade, "Design
Pattern, Elements of Reusable-Object Oriented Software.”

Now, I don't know about your field, but in software development there is one constant, change. Requirements change, tests change, platforms change, even customers change. The traditional “Waterfall” method of development does not allow for change without a lot of gnashing of teeth. So various methods over the years have tried to retrofit the waterfall model with flexibility. Some of the more famous are spiral development, rapid prototyping, and the Rational Unified Process (or RUP). None of these expected change to happen, they just tried to make it easier to handle.

Then came Agile development. Agile development was the created with the idea that change isn't bad. It isn't good, it just is. It will happen, so why no design your system from the begging to be fast, light, and flexible.

Now I am not a rocket scientist, but I have noticed a lot of the same problems in rocketry as in software. Missions are planned years in advance with very little flexibility for future discoveries or technologies. Missions are designed for a specific goal with specific technologies for that mission.

How does agile affect this? I am advocating an Agile Space Mission methodology. What Johnathan proposes goes a long way towards that. Whether it is libertarian or not, it s flexible. Re-fueling in space is not limited to the Moon. Mars missions, asteroid missions, Europa missions, could all use this technology. Orbit assembly with light rockets would work with many different mission goals. But the important thing is, it is flexible and scalable enough to work with situations we haven't even though of yet. That is the beauty of Agile, change is built into the entire process.

Don't get me wrong, we need to have goals. Going somewhere is important, but don't limit your mission architecture when you know you are going somewhere else later on. Plan for change...

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.