# Space Shuttle style programming

DevFeed: [Space Shuttle style programming](<https://devfeed.tech/articles/space-shuttle-style-programming-25334.md>)

Original publisher: [Read original article](<https://kau.sh/blog/space-shuttle-style-programming/>)

Author: Kaushik Gopal

Published: 2019-06-05T07:00:00Z

Content type: opinion

Language: en

Sources: [Kaushik Gopal's Site](<https://devfeed.tech/sources/kaushik-gopal-s-site.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Code](<https://devfeed.tech/topics/code.md>), [context](<https://devfeed.tech/topics/context.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [code](<https://devfeed.tech/tags/code.md>), [context](<https://devfeed.tech/tags/context.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [programming](<https://devfeed.tech/tags/programming.md>)

## AI overview

This commentary examines "Space Shuttle style" programming, a deliberately verbose approach associated with a Kubernetes controller. The style emphasizes explicit comments, considered branches, and preserving business context so future maintainers can understand complex binding behavior.

## Source excerpt

Sometime back I ran across a thread where folks talked about this programming style called "Space Shuttle style" that the Kubernetes codebase followed. // ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE FLYING. // ================================================================== // // This controller is intentionally written in a very verbose style. You will // notice: // // 1. Every 'if' statement has a matching 'else' (exception: simple error // checks for a client API call) // 2. Things that may seem obvious are commented explicitly // // We call this style 'space shuttle style'. Space shuttle style is meant to // ensure that every branch and condition is considered and accounted for - // the same way code is written at NASA for applications like the space // shuttle. // // Originally, the work of this controller was split amongst three // controllers. This controller is the result a large effort to simplify the // PV subsystem. During that effort, it became clear that we needed to ensure // that every single condition was handled and accounted for in the code, even // if it resulted in no-op code branches. // // As a result, the controller code may seem overly verbose, commented, and // 'branchy'. However, a large amount of business knowledge and context is // recorded here in order to ensure that future maintainers can correctly // reason through the complexities of the binding behavior. For that reason, // changes to this file should preserve and add to the space shuttle style. // // ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE FLYING. // ================================================================== To be clear: I don't follow the Space Shuttle style programming with my own code. However, I've noticed now that when I do comment my code, I'm a little more liberal with m