What the International Space Station (ISS) taught me about software systems

An Alternative ISS

Imagine the ISS was built in a manner reminiscent of your average, built-in-record-time and under high deadline pressure, brownfield software development project. You know the one I’m talking about – no developer wants to touch it.

Here is a list of some of the problems with this alternative, hypothetical version of the ISS:

• Habitation, life support, sanitation, science, recreational and engineering functions would be spread throughout the entire ISS and not be confined to dedicated locations. (Problem: Lack of Cohesion)
• The desire to make modifications to one function, say, sanitation, would also require changes to another, unrelated area, such as life support. (Problem: Undesirable Coupling)
• In order to expand the capacity of the ISS from 4 astronauts to 8 astronauts, most of the existing habitation area would need to be stripped out along with non-trivial modifications to the recreational and science areas. (Problem: Rigidity)
• Turning off the lights in one part of the ISS would also turn off the air scrubbers, that keep the air breathable, in another part of the ISS. (Problem: Fragility).

Not a pretty picture. A space station like that may well endanger the lives of the residing astronauts!

Note: I used to develop software in the way this hypothetical ISS was built. I was creating ‘bad’, by that I mean fragile, rigid software with lots of undesirable couplings for many years and I didn’t even know it! It took me years to see the light and accept that there is a better way to develop software. I’m not apologetic about it but I have learned and if I manage to help other developers avoid some of the traps lurking out there then I will consider myself happy.

Modular Design

But that is not how the real ISS was designed.

The genuine ISS was designed to be modular and is comprised of modules. Wikipedia’s second definition of a module is “a detachable self-contained unit of a spacecraft.” The ISS is a spacecraft so that definition is spot on.

A modular design makes the system pluggable. That means that we can attach and detach various modules to and from one another. I like to think of Lego blocks – you can stick two single blocks together to make a 2 block ‘system’. If you don’t like those two blocks stuck together like that anymore then you can easily pull them apart and stick them together differently or replace one of the blocks with another. A modular design makes a system easy to change.

Easy to Change

That is one of the reasons why the ISS was designed to be modular – so it is easy (read: quicker and cheaper) to change. (The other reason is that existing space vehicles can be used to ferry the smaller and lighter modular components into earth orbit).

An easy-to-change system can cope with changing business requirements. So, modularity in a software system does not necessarily show its advantages right away but once requirements change, which they very often do, a modular design will pay dividends.

On the real ISS each type of module serves a singular purpose. For example, there are modules for habitation, life support, engineering and science. Plug them together and hey presto, now we have a space station that is functional.

The magic doesn’t stop there though. What if requirements had changed and now the ISS needed to support 8 rather than just 4 astronauts? What can we do? Well, we could simply unplug the existing habitation module and plug in the larger habitation module. Imagine if instead it took 6 months of re-engineering in space costing hundreds of millions of dollars! Ouch.

Reuse

Furthermore, modular design also enables reuse. A pluggable habitation module can be reused on the same space station or on another one as long as the connector on our module fits the connector on another module.

What works for space station design also works for software system designs. Can’t scale with the existing database? Plug in a different one. No longer want maintain your own SMTP server? Switch out your SMTP emailer for a cloud service emailer. And so on.

I have found that when I design my subsystem interfaces well I can often end up in a virtuous cycle where each additional module is reusable and adding more and more value to the existing ecosystem of pluggable modules. Compare that with highly coupled, non-cohesive systems where no reuse is possible and similar functionality must be written from scratch each time.

Problems Solved

Let’s take a closer look at the 4 problems that plagued our Gedankenexperiment ISS and compare those problems to the modular, real ISS:

• Cohesion, or the notion that a module has a singular purpose only and fulfills that purpose very well, is a first class citizen in a modular design. All functions pertaining to one capability are housed in the same module.
• Unnecessary Coupling, or the presence of extraneous dependencies between modules, will be almost non-existent in the actual ISS because the modules, in order to be easily pluggable, must have minimal dependencies on one another.
• Rigidity, whereby modifications to one functional area require a multitude of changes in this functional area and possibly unrelated ones, would be a thing of the past. Modular design, and the ensuing high cohesion of each component, as well as the replaceability of each component with one more suited to changed requirements are going to help here.
• Fragility, where a problem in one area of our space station causes problems in seemingly unrelated parts are greatly mitigated when there is a high level of Cohesion in each module.

Conclusion

I strongly believe modular design is a sign of well thought out software produced by a mature developer who cares about the code she writes. It takes time and effort to learn how to create modular systems – I should know, it took me many years. However, once the switch is flicked it is almost impossible (in my own case at least) to go back to writing expedient, technical debt laden, low quality code. When you succeed in producing high quality modular systems you will have mastered one of the core concepts of the software development practice.