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.