{"id":6329,"date":"2022-02-22T17:49:34","date_gmt":"2022-02-23T00:49:34","guid":{"rendered":"https:\/\/mattfife.com\/?p=6329"},"modified":"2022-02-22T17:54:53","modified_gmt":"2022-02-23T00:54:53","slug":"the-write-stuff","status":"publish","type":"post","link":"https:\/\/mattfife.com\/?p=6329","title":{"rendered":"The Write Stuff"},"content":{"rendered":"\n

What does it take to write software that lives depend on and send rockets to space? Fast Company wrote a great article<\/a> of the software engineers that delivered that software for the Space Shuttle. Particularly noteworthy is the observations of Quinn Larson, 34, had worked on shuttle software for seven years when he left to go to work for Micron Technology automating the saws that cut finished chip wafers to the right size. \u201cIt was up to me to decide what to do,\u201d says Larson. \u201cThere were no meetings, there was no record-keeping.\u201d He had freedom; it was a real kick. But to Larson\u2019s way of thinking, the culture didn\u2019t focus on, well, the right stuff. \u201cSpeed there was the biggest thing,\u201d. Larson eventually went back at the shuttle group. \u201cThe people here are just of the highest caliber,\u201d he said on his first day back in Clear Lake.<\/p>\n\n\n\n

In interviewing the Shuttle team, they boiled down to 4 key principles that set the development team apart from other software teams:<\/p>\n\n\n\n

1. The product is only as good as the plan for the product.<\/span> At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do \u2014 and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change.<\/p>\n\n\n\n

2. Within the whole software team, the team is broken into two seperate groups: the coders and the verifiers<\/span>. The two outfits report to separate bosses and function under opposing marching orders. The development group is supposed to deliver completely error-free code, so perfect that the testers find no flaws at all. The testing group is supposed to pummel away at the code with flight scenarios and simulations that reveal as many flaws as possible.<\/p>\n\n\n\n

3. The software consists of the code and two enormous databases<\/span>. There is the software. And then there are the databases beneath the software, two enormous databases, encyclopedic in their comprehensiveness. One is the history of the code itself \u2014 with every line annotated, showing every time it was changed, why it was changed, when it was changed, what the purpose of the change was, what specifications documents detail the change. Everything that happens to the program is recorded in its master history. <\/p>\n\n\n\n

The other database \u2014 the error database \u2014 stands as a kind of monument to the way the on-board shuttle group goes about its work. Here is recorded every single error ever made while writing or working on the software, going back almost 20 years. For every one of those errors, the database records when the error was discovered; what set of commands revealed the error; who discovered it; what activity was going on when it was discovered \u2014 testing, training, or flight. It tracks how the error was introduced into the program; how the error managed to slip past the filters set up at every stage to catch errors \u2014 why wasn\u2019t it caught during design? during development inspections? during verification? Finally, the database records how the error was corrected, and whether similar errors might have slipped through the same holes.<\/p>\n\n\n\n

4. Don\u2019t just fix the mistakes \u2014 fix whatever permitted the mistake<\/span>. Importantly, the group avoids blaming people for errors. The process assumes blame \u2013 and it\u2019s the process that is analyzed to discover why and how an error got through. At the same time, accountability is a team concept: no one person is ever solely responsible for writing or inspecting code. \u201cYou don\u2019t get punished for making errors,\u201d says Marjorie Seiter, a senior member of the technical staff. \u201cIf I make a mistake, and others reviewed my work, then I\u2019m not alone. I\u2019m not being blamed for this.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"

What does it take to write software that lives depend on and send rockets to space? Fast Company wrote a great article of the software engineers that delivered that software for the Space Shuttle. Particularly noteworthy is the observations of Quinn Larson, 34, had worked on shuttle software for seven years when he left to go to work for Micron Technology automating the saws that cut finished chip wafers to the right size. \u201cIt was up to me to decide…<\/p>\n

Read More Read More<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[9,7,5],"tags":[],"class_list":["post-6329","post","type-post","status-publish","format-standard","hentry","category-cool","category-technicalprogramming","category-technical"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p4WECr-1E5","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/mattfife.com\/index.php?rest_route=\/wp\/v2\/posts\/6329","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mattfife.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mattfife.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mattfife.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/mattfife.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6329"}],"version-history":[{"count":3,"href":"https:\/\/mattfife.com\/index.php?rest_route=\/wp\/v2\/posts\/6329\/revisions"}],"predecessor-version":[{"id":6332,"href":"https:\/\/mattfife.com\/index.php?rest_route=\/wp\/v2\/posts\/6329\/revisions\/6332"}],"wp:attachment":[{"href":"https:\/\/mattfife.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mattfife.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6329"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mattfife.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}