Thoughtful Modularity

I spent most of the first week of December down at NASA’s Kennedy Space Center for the launch of Orion, NASA’s next-generation spacecraft. As part of NASA Social, I was lucky enough to get some behind-the-scenes tours, and to talk with scientists, engineers, astronauts, and even the Administrator himself.

The day before launch, there was a two-hour event featuring the leaders of various NASA departments, with the discussion centered on Orion’s future missions—including the first (of hopefully many) crewed journeys to Mars. William Gerstenmaier, NASA’s Associate Administrator for Human Exploration and Operations, had some interesting comments about the technology that will get us there (55 minutes into the event):

This is quite a shift in strategy for NASA. The Apollo and the Shuttle programs were riddled with rigidity. One engineer I talked with said that contractors received more than 12,000 requirements for the Shuttle’s development. Orion has just over 300—a clear move toward flexibility.

It’s not only the unpredictable political minefield that NASA plays in pushing them to modularity, it’s the fact that the final pieces making a crewed mission to Mars possible are still in the works. If something revolutionary is learned about the habitability of Mars from rovers there over the next few years, NASA needs to be able to incorporate those findings into the plans.

Most of our projects operate on a smaller scale than a mission to Mars, but there’s a lot we can learn from this approach. NASA isn’t just planning for modularity in terms of how things interface with each other, they’re planning for it at the core level of each component. Rather than stopping at a common docking mechanism (a common API, of sorts), they’re building rockets, landers, and habitation modules that can be modified as breakthroughs are made.

In a lot of ways, we’re already doing this in our work, whether we realize it or not. The rising focus on design systems and pattern libraries shows that we’ve got a knack for breaking something down to its smallest components. By building up from those small components, we’re able to swap out anything, big or small, at any time. If a button style isn’t working, it can be changed painlessly. If the entire header needs to be reconsidered after user testing, it’s self-contained enough to not disturb the rest of the site.

With the help of new-age content management systems like Craft, we’re able to be more modular by decoupling the front-end interface from the way data is stored and managed on the backend. That means that either side can be upgraded, rewritten, or changed entirely, without the other being dependent on it.

Tim Berners-Lee has been talking about modularity as a central principle of the web for quite a while:

NASA’s strategies echo his thoughts on the web: build modularly for the future while realizing that the future is unknown. New discoveries will be made, new things will be built, and technology will improve.

If you think authentication is about to undergo a major revolution with the rise of cheap biometrics, you may plan and build your system differently than assuming it will always be password based. The goal is to build in an open-ended way, so as things change and progress, those innovations can be implemented with ease.

That’s not an impossible task, either. Just take a look at Amazon—they haven’t had a major, sitewide redesign in more than a decade, and the industry has changed in massive ways. I’m sure the behind-the-scenes infrastructure has changed, but users haven’t been aware of it. Amazon has been tweaking and iterating for years, improving their product to their customers’ satisfaction.

The implementation details of our work will always be in flux, but the goals of our product will remain the same. Be modular in implementation so that what you build can reap the benefits of the future.