{"id":90,"date":"2021-03-19T12:51:16","date_gmt":"2021-03-19T19:51:16","guid":{"rendered":"http:\/\/www.barrybriggs.com\/blog\/?p=90"},"modified":"2021-03-19T12:52:10","modified_gmt":"2021-03-19T19:52:10","slug":"i-learned-about-from-that-a-meditation-on-bugs","status":"publish","type":"post","link":"http:\/\/www.barrybriggs.com\/blog\/programming\/i-learned-about-from-that-a-meditation-on-bugs\/","title":{"rendered":"I Learned About * from That: A Meditation on Bugs"},"content":{"rendered":"\n

By Barry Briggs
Second in a series: previous<\/a><\/p>\n\n\n\n

[Programming note: I have changed the title of this series\nfrom \u201cI Learned About Programming from That\u201d to \u201cI Learned About * from That,\u201d\nthe idea being I\u2019ll probably talk about lessons learned not only regarding\nprogramming but also lots of other areas \u2013 in computing \u2013 as well. * (star, or\nwild-card) as I\u2019m sure most of you know means \u201canything and everything\u201d in\ncomputer-talk. Everybody got that? Now back to your regular show.] <\/p>\n\n\n\n

So, with just a smattering of\ntheory and a tiny bit of FORTRAN training under my belt, I somehow got hired to\nwork at Goddard Space Flight Center. <\/p>\n\n\n\n

Yep.<\/p>\n\n\n\n

[What\u2019s FORTRAN, you ask? It\u2019s one of the earliest high-level languages, targeted primarily at scientific and engineering applications. It stands for FORmula TRANSlation and it\u2019s always capitalized. Back then it was one of the two more popular languages, the other being COBOL, a business-focused language.]<\/em><\/p>\n\n\n\n

And with my extensive background in computer science, where\ndid I get assigned? To write operating system-level code in assembly language\nfor the giant Univac 1100 mainframe that controlled communications for the\nfirst Tracking and Data Relay Satellite (TDRS, pronounced tee-dress<\/em>; see\nthe image below). <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Fortunately, one of the great things about\nyouth is you often don\u2019t know what you\u2019re not supposed to be able to do, and so\nI dove in. (And there\u2019s a lesson right here: be FEARLESS!)<\/p>\n\n\n\n

But…talk about being at the wrong end of a firehose! Our little team was charged with writing an entire transaction processing monitor (a pretty new concept at the time) for the applications group whose apps sent and received commands and data to the satellite (which controlled communications to the Space Shuttle). Their apps involved positioning it correctly, connecting to ground stations, correcting errors, and all kinds of stuff I don\u2019t remember. <\/p>\n\n\n\n

Moreover, the topology of the computing environment was\nnothing if not complex: ; it connected to a bunch of Varian minicomputers which\ndid preprocessing and a bunch of PDP-11s which did reporting (I think). The\nmainframe itself was a multiprocessor, so we had to use semaphores, test-and-sets,\nand locks; daunting stuff for a very junior programmer! And all our code ran at\nthe highest privilege levels which means it was pretty easy for us to bring the\nwhole kit and kaboodle down if we had bugs. <\/p>\n\n\n\n

Which I did a few times, early on. <\/p>\n\n\n\n

On the other hand, there were some cool aspects. Everything\nwas open-source, so if you wanted to know how the operating system\u2019s task\nscheduler worked, you could just go look \u2013 in the multi-thousand-page printout.\n<\/p>\n\n\n\n

Because millions of dollars and for that matter, lives (of\nastronauts), depended directly or indirectly on our code, we were very careful.\nEvery line of code that was written was reviewed. Let me tell you, those first\nfew code reviews were not a lot of fun for that young newbie that I was. <\/p>\n\n\n\n

Eventually, however, I got pretty disciplined in writing and\ntesting my own code, and eventually got to the point where I flew through the\ncode reviews. <\/p>\n\n\n\n

The thing was, no one complained about them, really, because\nwe all knew that so much was riding on what we did. <\/p>\n\n\n\n

Commercial Computing is, or was, Very Different <\/h2>\n\n\n\n

It was a big surprise to me, then, when I entered the world of\ncommercial computing, that programmers had rather a more relaxed view toward\nbugs. In fact, I was quite shocked that we\u2019d have serious discussions (and am\nto this day) about how many \u201cseverity-1\u201d bugs we could ship with! <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Working on one major commercial project \u2013\na release of Lotus 1-2-3 \u2013 we were actually awarded tchotchkes like the one shown\nfor the number of bugs we programmers fixed. You can imagine that this was a pretty\neasy metric to track! <\/p>\n\n\n\n

However, somewhere along the line someone realized that\nthere were fundamental things wrong with the development process:<\/p>\n\n\n\n

  1. In the early phases of the project, developers\nwere rewarded for a feature working \u2013 even if just barely \u2013 in other words, in\nprototype quality.
    \n
    \n<\/li>
  2. Later in the project, developers were rewarded\nfor patching the prototypes they\u2019d created early on.
    \n
    \n<\/li>
  3. And (therefore) just maybe it would be better to\nreward developers for checking in clean code in the first place. Not as easy a\nmetric to track, but nevertheless rewarding the right behavior.<\/li><\/ol>\n\n\n\n

    Automated Testing: Present at the Creation<\/h2>\n\n\n\n

    How did our QA teams find all these bugs? Of course, back in\nthe Jurassic we had armies of hardworking folks doing feature testing \u2013 taking a\nbuild from us developers each week and trying out each feature to see what\nworked, what still didn\u2019t, what worked last week but didn\u2019t this week, and so\non. <\/p>\n\n\n\n

    Well, the product of course had a macro facility. Somebody\nrealized along the way that we could use the product to test itself! <\/em>And\nso our test teams moved from being feature testers to macro experts, and\nperhaps this was the birth of the profession we now commonly call SDET \u2013 Software\nDevelopment Engineer in Test, for the uninitiated. (For historical purposes,\nthe person who came up with the original idea was the late Mike Kleinert; the\nperson who refined, drove, and scaled it was the young woman who later became\nmy wife.)<\/p>\n\n\n\n

    The Purpose of Testing <\/h2>\n\n\n\n

    Over time I realized something which I think is commonly\nunderstood now, which is that the purpose of testing is not, in the final analysis,\nto find bugs, although that is certainly a core part of the job. <\/p>\n\n\n\n

    In fact \u2013 and incidentally I use this as an interview\nquestion \u2013 the function of test is to determine the product\u2019s readiness to ship.\nWhen leading software development projects, therefore, I never asked the\narchitect or the developers if the product was ready (you\u2019ll either get \u201cI\u2019m\nsick of this damn thing, ship it\u201d or the perfectionist \u201cI have to refactor\neverything first\u201d). <\/p>\n\n\n\n

    Instead it\u2019s the test team that is, or should be, closest to the customer\/user and their experiences. So at the end of the day they have the final say. And in my view the head of test has the single most important decision-making power in the entire team: when we’re done!<\/p>\n\n\n\n

    That\u2019s it for this installment. I have lots more in the\nqueue, so watch this space. And I look forward to your comments! <\/p>\n","protected":false},"excerpt":{"rendered":"

    By Barry BriggsSecond in a series: previous [Programming note: I have changed the title of this series from \u201cI Learned About Programming from That\u201d to \u201cI Learned About * from That,\u201d the idea being I\u2019ll probably talk about lessons learned not only regarding programming but also lots of other areas \u2013 in computing \u2013 as … <\/p>\n

    Continue reading “I Learned About * from That: A Meditation on Bugs”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"episode_type":"","audio_file":"","cover_image":"","cover_image_id":"","duration":"","filesize":"","date_recorded":"","explicit":"","block":"","filesize_raw":"","footnotes":""},"categories":[9],"tags":[],"class_list":["post-90","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/posts\/90","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/comments?post=90"}],"version-history":[{"count":7,"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/posts\/90\/revisions"}],"predecessor-version":[{"id":100,"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/posts\/90\/revisions\/100"}],"wp:attachment":[{"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/media?parent=90"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/categories?post=90"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.barrybriggs.com\/blog\/wp-json\/wp\/v2\/tags?post=90"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}