By Barry Briggs
Second in a series: previous
[Programming note: I have changed the title of this series from “I Learned About Programming from That” to “I Learned About * from That,” the idea being I’ll probably talk about lessons learned not only regarding programming but also lots of other areas – in computing – as well. * (star, or wild-card) as I’m sure most of you know means “anything and everything” in computer-talk. Everybody got that? Now back to your regular show.]
So, with just a smattering of theory and a tiny bit of FORTRAN training under my belt, I somehow got hired to work at Goddard Space Flight Center.
Yep.
[What’s FORTRAN, you ask? It’s one of the earliest high-level languages, targeted primarily at scientific and engineering applications. It stands for FORmula TRANSlation and it’s always capitalized. Back then it was one of the two more popular languages, the other being COBOL, a business-focused language.]
And with my extensive background in computer science, where did I get assigned? To write operating system-level code in assembly language for the giant Univac 1100 mainframe that controlled communications for the first Tracking and Data Relay Satellite (TDRS, pronounced tee-dress; see the image below).
Fortunately, one of the great things about youth is you often don’t know what you’re not supposed to be able to do, and so I dove in. (And there’s a lesson right here: be FEARLESS!)
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’t remember.
Moreover, the topology of the computing environment was nothing if not complex: ; it connected to a bunch of Varian minicomputers which did preprocessing and a bunch of PDP-11s which did reporting (I think). The mainframe itself was a multiprocessor, so we had to use semaphores, test-and-sets, and locks; daunting stuff for a very junior programmer! And all our code ran at the highest privilege levels which means it was pretty easy for us to bring the whole kit and kaboodle down if we had bugs.
Which I did a few times, early on.
On the other hand, there were some cool aspects. Everything was open-source, so if you wanted to know how the operating system’s task scheduler worked, you could just go look – in the multi-thousand-page printout.
Because millions of dollars and for that matter, lives (of astronauts), depended directly or indirectly on our code, we were very careful. Every line of code that was written was reviewed. Let me tell you, those first few code reviews were not a lot of fun for that young newbie that I was.
Eventually, however, I got pretty disciplined in writing and testing my own code, and eventually got to the point where I flew through the code reviews.
The thing was, no one complained about them, really, because we all knew that so much was riding on what we did.
Commercial Computing is, or was, Very Different
It was a big surprise to me, then, when I entered the world of commercial computing, that programmers had rather a more relaxed view toward bugs. In fact, I was quite shocked that we’d have serious discussions (and am to this day) about how many “severity-1” bugs we could ship with!
Working on one major commercial project – a release of Lotus 1-2-3 – we were actually awarded tchotchkes like the one shown for the number of bugs we programmers fixed. You can imagine that this was a pretty easy metric to track!
However, somewhere along the line someone realized that there were fundamental things wrong with the development process:
- In the early phases of the project, developers
were rewarded for a feature working – even if just barely – in other words, in
prototype quality.
- Later in the project, developers were rewarded
for patching the prototypes they’d created early on.
- And (therefore) just maybe it would be better to reward developers for checking in clean code in the first place. Not as easy a metric to track, but nevertheless rewarding the right behavior.
Automated Testing: Present at the Creation
How did our QA teams find all these bugs? Of course, back in the Jurassic we had armies of hardworking folks doing feature testing – taking a build from us developers each week and trying out each feature to see what worked, what still didn’t, what worked last week but didn’t this week, and so on.
Well, the product of course had a macro facility. Somebody realized along the way that we could use the product to test itself! And so our test teams moved from being feature testers to macro experts, and perhaps this was the birth of the profession we now commonly call SDET – Software Development Engineer in Test, for the uninitiated. (For historical purposes, the person who came up with the original idea was the late Mike Kleinert; the person who refined, drove, and scaled it was the young woman who later became my wife.)
The Purpose of Testing
Over time I realized something which I think is commonly understood now, which is that the purpose of testing is not, in the final analysis, to find bugs, although that is certainly a core part of the job.
In fact – and incidentally I use this as an interview question – the function of test is to determine the product’s readiness to ship. When leading software development projects, therefore, I never asked the architect or the developers if the product was ready (you’ll either get “I’m sick of this damn thing, ship it” or the perfectionist “I have to refactor everything first”).
Instead it’s 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!
That’s it for this installment. I have lots more in the queue, so watch this space. And I look forward to your comments!
Comments are closed.