I was nervous.
At seventeen, I didn’t lack for confidence. I was one of the “hams” of the Junior class at Timberline High School. So, it wasn’t the classroom presentation that was making me nervous it was my TI 99 Home Computer.
(Not my original TI99)
I spent much of the spring of 1982 learning a language called BASIC and writing a program for my International Relations Class (The same one I talked about in When Cops Interrupt Your Conference Call.) The program was pretty simple. Which was good since the computer was pretty simple.
I took a political survey and presented it as a series of questions and answers. Today I’d do the whole thing in PowerPoint and be done in a couple hours. In 1982, there was no PowerPoint. I had to write code to display the screen. I had to write code to play the music. I had to write code for everything. It took a long time. Probably about 100 hours or more. Each time I would load the code, modify it and then save it. . . to a cassette tape.
There were no thumb drives in 1982. (Well, I had a friend who nearly wrecked while thumb driving, but that was totally different.) There were no floppy drives. Writing code for the TI99 meant hooking up a tape recorder.
And the tape recorder came with a counter so that you would know how long to “play” your program into memory.
Everyday I’d play my program into memory, work on it and save it back out again. Today, though, I wasn’t writing code. It was time to finally show what I had learned and built. Looking back now, I probably should have tested it before getting in front of the class. I didn’t. . . and that made all the difference.
Testing is, of course, good software practice. At Agile studios we had a developer who one time said,
I haven’t tested my code, but I’m sure it will work.
We mocked him incessantly for that statement. You ALWAYS test. And then you test again. And you keep doing that until it is absolutely perfect or you run out of time. (It’s never perfect. You always run out of time.)
But, are there times where testing is a bad idea? I can think of a classic example.
Obviously, you cannot test individual matches. The test uses up the match. Bullets, fit into the category as well.
There are a few things for which testing first is not a good idea, but software isn’t one of those things.
Developing software at Microsoft involved a specific process. Each group had their role, Program Management, Development and Testing each are involved in the process. When it gets close to shipping, Testing “owns” the code. In other words, The PM cannot tell Testing to release the code to manufacturing. Development cannot force Testing to release. The Test Manager has ultimate control over what goes out the door. And he wants to make sure that product is tested in as many ways as possible.
Microsoft never released a piece of software with any known bugs.
Anyone who has used Windows just spit their morning coffee all over their keyboard.
There’s a trick to it, of course. The Test team couldn’t release until their bug queue, the list of errors, was empty. They simply reclassified certain “issues” as non-bugs. That got them out of the queue. But, they really did try to catch the big ones. No one in IT or development wants to release buggy code. So, we test.
But, back in 1982, I didn’t know a lot about programming or the development process. I didn’t test. I simply loaded my program into memory as the class settled into their seats.
The presentation was a smashing success. I got an A+ on the project. And it performed flawlessly. When the class was over, I felt drained. I shut off the TV that I used as monitor and hit the power switch on the computer.
That was the last I ever saw my program. One hundred hours of work just gone. The next time I tried to load my program all I got was gibberish off my tape. I tried it again and again. No luck. That program was gone for good.
So, what happened? It was the tape. My tape was a 90 minute tape. My program took about 5 minutes of that. Every time I read my program into memory the tape would stretch slightly. That didn’t matter because every time I loaded my program into memory, I later wrote it back to the tape. This fresh recording wasn’t yet stretched.
Every time except the last time. The last time I read it off the tape and didn’t modify it. Why would I? It was a presentation. The tape stretched and the next time I tried to read it, I got just a bunch of noise. Had I done a practice run, my practice run would have gone successfully but then the final would have been with the corrupt tape version.
Sometimes, even in software it pays to not test it first!
Rodney M Bliss is an author, columnist and IT Consultant. He lives in Pleasant Grove, UT with his lovely wife and thirteen children and one grandchild.
Follow him on
Twitter (@rodneymbliss)
Facebook (www.facebook.com/rbliss)
LinkedIn (www.LinkedIn.com/in/rbliss)
or email him at rbliss at msn dot com