Software Engineering

4 Articles

Not All SpaceX Software Goes To Space

June 1, 2021 by 13 Comments

SpaceX has always been willing to break from aerospace tradition if they feel there’s a more pragmatic solution. Today this is most visible in their use of standard construction equipment like cranes in their Starship development facility. But the same focus on problem solving can also be found in their software parts we don’t see. Recently we got two different views behind the scenes. First, a four-part series about “software in space” published by StackOverflow blog, followed quickly by an Ask Me Anything (AMA) session on SpaceX Reddit.

Some of the StackOverflow series cover ground that has been previously discussed. Mostly in the first part dealing with their workhorse Falcon and Dragon vehicles, and some in the second part discussing Starlink whose beta program is reaching more and more people. Both confirmed that spaceflight software has to meet very stringent requirements and are mostly close to the metal bespoke C++ code. But we receive fascinating new information in part three, which focuses on code verification and testing. Here they leverage a lot of open source infrastructure more common to software startups than aerospace companies. The fourth and final component of this series covers software to support SpaceX hardware manufacturing, which had been rarely discussed before this point. (Unfortunately, there was nothing about how often SpaceX software developers copy and paste code from StackOverflow.)

The recent Reddit AMA likewise had some overlap with the SpaceX software AMA a year ago, but there were new information about SpaceX work within the past year. There was Crew Dragon’s transition from a test to an operational vehicle, and the aforementioned Starship development program. Our comments section had a lot of discussion about the practicality of touchscreen interfaces in real spacecraft, and here we learn SpaceX put a lot of study into building something functional and effective.

It also showed us that essentially every Sci-Fi Movie Interface was unrealistic and would be unreadable under extreme conditions.

In the course of this research, they learned a lot of pitfalls about fictional touch interfaces. Though to be fair, movie and television spacecraft UI are more concerned about looking cool than being useful.

If the standard AMA format is not to your liking, one of the contributors compiled all SpaceX answers alongside their related questions in a much more readable form here. And even though there’s an obvious recruiting side to these events, we’re happy to learn more about how SpaceX have continued to focus on getting the job done instead of rigidly conforming to aerospace tradition. An attitude that goes all the way back to the beginning of this company.

Playing The Interview Game

April 12, 2021 by 37 Comments

Technical interviews are generally dreaded, just like every other interview. However, technical interviews include many elements that non-technical folks might find mystifying or even pointless, such as whiteboard problem solving, take-home assignments, design sessions, or even just straight brain teasers. [Erik McClure] went a bit off the beaten path and started using the factory builder game Factorio as a technical interview.

Many point to the intent behind the problems and tricky questions inherent in whiteboard coding exercises and assert that the focus is not to complete the problem, but rather to expose how a candidate thinks and problem solves. Factorio is all problem-solving as you work as a team to slowly scale up a humble production line to a massive factory, which makes it a good candidate for assessing these sorts of skills. We doubt that the fine developers who wrote the game ever imagined it being used as an interview.

In all likelihood, you probably won’t have a Factorio interview anytime soon as [Erik] estimated each interview would take between eight and twenty hours. But we love the idea of reimagining the interview from a tedious set of problems to solve to an evolving cooperative game. Of course, you can also read more about getting the experience necessary for a job and what companies are looking for in an interview.

A trailer for Factorio is after the break.

Continue reading “Playing The Interview Game” →

Code Craft-Embedding C++: Hidden Activities?

November 20, 2015 by 34 Comments

What is an embedded system? The general definition is a computer system dedicated to a specific purpose, i.e. not a general purpose system usable for different tasks. That is a very broad definition. I was just skimming the C++ coding guidelines for the Joint Strike Fighter. That’s a pretty big embedded system and the first DOD project that allowed C++! When you use an ATM to get money you’re using an embedded system. Those are basically hardened PCs. Then at the small end we have all the Internet of Things (IoT) gadgets.

The previous articles about embedding C++ discussing classes, virtual functions, and macros garnered many comments. I find both the positive and critical comments rewarding. More importantly, the critical comments point me toward issues or questions that need to be addressed, which is what got me onto the topic for this article. So thank you, all.

Let’s take a look at when embedded systems should or should not use C++, taking a hard look at the claim that there may be hidden activities ripe to upset your carefully planned code execution.

Continue reading “Code Craft-Embedding C++: Hidden Activities?” →

Killed By A Machine: The Therac-25

October 26, 2015 by 145 Comments

The Therac-25 was not a device anyone was happy to see. It was a radiation therapy machine. In layman’s terms it was a “cancer zapper”; a linear accelerator with a human as its target. Using X-rays or a beam of electrons, radiation therapy machines kill cancerous tissue, even deep inside the body. These room-sized medical devices would always cause some collateral damage to healthy tissue around the tumors. As with chemotherapy, the hope is that the net effect heals the patient more than it harms them. For six unfortunate patients in 1986 and 1987, the Therac-25 did the unthinkable: it exposed them to massive overdoses of radiation, killing four and leaving two others with lifelong injuries. During the investigation, it was determined that the root cause of the problem was twofold. Firstly, the software controlling the machine contained bugs which proved to be fatal. Secondly, the design of the machine relied on the controlling computer alone for safety. There were no hardware interlocks or supervisory circuits to ensure that software bugs couldn’t result in catastrophic failures.

The case of the Therac-25 has become one of the most well-known killer software bugs in history. Several universities use the case as a cautionary tale of what can go wrong, and how investigations can be lead astray. Much of this is due to the work of [Nancy Leveson], a software safety expert who exhaustively researched the incidents and resulting lawsuits. Much of the information published about the Therac (including this article) is based upon her research and 1993 paper with [Clark Turner] entitled “An Investigation of the Therac-25 Accidents”. [Nancy] has since published updated information in a second paper which is also included in her book.

Continue reading “Killed By A Machine: The Therac-25” →