What the International Space Station Taught me about How to Design Software Systems
An Alternative International Space Station
The International Space Station (ISS) is one of humanity’s greatest achievements. Similar in difficulty to sending a man to the moon. It’s a masterpiece of engineering.
Now, imagine that the engineering was not so exceptional. Imagine, engineers had built the ISS how we usually write software. What kind of problems might our imaginary ISS have?
Here are some I can think of:
- Engineers spread Habitation, Life Support, Sanitation, Science, Recreational and Support services throughout the space station. The problem of functions smeared across several areas is called Functional Smear.
- Modifying one capability, say, Sanitation, requires changes to a separate area, like Life Support. Our ISS is suffering from Unnecessary Coupling.
- New orders demand an increased science workload from the ISS. Engineers are forced to rebuild the Science area completely. Besides, Life Support and Sanitation functions are also affected. The ISS design is resistant to change — Rigidity is the issue.
- Turning off lights in the Recreation area also silently turns off Life Support. A system is fragile when a problem in one area causes problems in a separate area. Our hypothetical ISS is displaying signs of Fragility.
Not a pretty picture. A space station like that would endanger the lives of its astronauts.
Modular Design
Luckily, engineers did not design the ISS this way.
The real ISS was created to be modular.
A modular design makes a system pluggable. That means we can attach and detach modules to and from one another. A modular design creates a system easy to change.
Easy to Change
The real ISS is made up of several different types of modules. Each type of module serves a singular, unified (or cohesive) purpose. There are modules for Recreation, Life Support, Engineering, Science and more. Put them together to build a functional space station.
What about when requirements change? Say, the ISS now needs to support more astronauts. What can we do? We could unplug the existing Life Support module and replace it with a more powerful one.
An easy-to-change system can cope with changing business requirements. Easy-to-change also means cheaper and faster to change.
The same architecture that makes the ISS easy to change also applies to software systems: Can’t scale with the existing database? Plug in a different one. Had enough of maintaining your SMTP server? Switch out your SMTP emailer for a cloud service emailer.
Reuse
A modular design is reusable. A pluggable Science module could be plugged into another space station as long as the plug (or interface) is the same.
The same principle applies to software modules. Creating well-designed interfaces for pluggable components creates opportunities for reuse. With time, it becomes easier to construct software systems with the existing modules and their interfaces.
Compare that with a highly coupled, non-cohesive system where the code reuse is difficult. Over time the system becomes rigid and resistant to change. It takes developers longer and longer to make changes in this system. These systems are also fragile. A small change in one place is likely to cause problems in other areas. This situation is unpleasant for software developers and management alike.
Problems Solved
Let’s take a closer look at the 4 problems that plagued our Gedankenexperiment ISS and compare those problems to the modular ISS:
- Functional Smear — Does not apply to the actual ISS. Functionality is concentrated to separate modules. The Science module is only for science experiments. The Life Support module maintains the breathable atmosphere. No other module should perform the same function (unless for reasons of redundancy).
- Unnecessary Coupling, or the presence of unneeded dependencies between modules, are certainly almost non-existent in the actual ISS. To be easily pluggable the modules must have no (or only minimal) dependencies on one another.
- Rigidity — This is the tendency of modification to be challenging to carry out. The pluggable design of the real ISS means that a module can be unplugged and replaced with a differently capable module.
- Fragility — is the property of a system where a problem in one area also causes problems in another area. Fragility on a space station can be deadly. Engineers will have minimised the effect of Fragility in the ISS.
Conclusion
I believe modular design is the hallmark of a well thought out software system. A sign of a mature developer who cares about the code she writes. It takes time and effort to learn how to create pluggable systems — I know it took me a long time. However, once insight replaces ignorance, it is almost impossible, to go back to writing low-quality code.
Let’s all get better at developing software.
If you enjoyed this article, please leave some claps — and a bunch of claps if you loved it! :) Thank you kindly.
Join my email list to fast-track your software engineering career.
When signing up, you’ll get my guide, ‘The Road to Master Progammer’, containing 3 powerful ideas to help you shorten your journey to expert programmer.
