Programming - it was acceptable in the 80s ...

Let’s turn back the clock, way back.  I've plundered some of my memories for this blog before, though usually they’re the somewhat traumatic parts of my past.  My life isn't always so serious, and so something fun has been long overdue ...

At work, I've been telling a few tales about my experience with programming in the 80s.  Oh I'm sounding quite the great-grandfather of IT.  But I think in telling how we got here, there's some important things we can pick out.  I have to take you back as Life On Mars would put it, to a time that’s “like living on another planet”.

In the 70s, we didn't have computers in the home.  My dad worked at a large mining research establishment, and they had one single huge computer that ran things like the payroll.  Everything he needed to do he did on paper,

• if he needed to make a graph, he used graph paper not Excel
• if he needed something typed up there was a lady from the secretarial pool who’d work from his notes
• if he needed something filing it went into a cardboard folder in the filing cabinet

How science fiction made us think of computers ...

To me, computers were something that you saw on the bridge of the Starship Enterprise or trying to take over the world in Doctor Who.  And it’s probably exactly because of this that I became so interested, imagining the mischief I could reek!  We had a book in our junior school library – Ladybird’s “How computers work”, that I regularly took out.  I even asked my junior school teacher Mr Appleby what skills I’d need to work with computers, to which he said I needed to stop fantasising, as they were just a fleeting fad (what a great advert for education, actually discouraging the next generation from learning and asking questions).

Then in the 80s, something magical happened – the home computer!  Companies were developing mass manufactured entry level machines.  Suddenly from having a life plan of 6 more years at school focusing on maths and then maybe getting my hands on a computer, I was able to skip straight to the “get your hands on a computer” part.  And in Christmas 1982, whilst my brother got upgraded to a new bike, my dreams came true when I got a ZX Spectrum.

The ZX Spectrum was a popular computer in the United Kingdom, and one of the first affordable home computers here.  Many remember it for a few of it's quirk, the one oft quoted being to save money and make it affordable, it had a rubber keyboard which made programming “interesting” (I'm now a proficient touch typist, and the thought of using a rubber keyboard again makes me think how slow it would be).

Home computers at the time used a feed to a TV to function as a monitor, and used a tape recorder to load/save programs.  It was a slow process, but then we didn't know better at the time.  Typically you’d set the machine to load, check it had started then go to the toilet, make a cup of tea, and return to hope it was all done.

The ZX Spectrum came with a manual and a sample tape which included a few demo programs.  No-one really knew what was going to be popular, so included on there were a few educational programs (if I remember mathematically simulating fox and hare populations as well as Conway’s life algorithm), together with a couple of games (a Space Invaders and Pacman clone).

In that first couple of years, the ZX Spectrum didn't initially have a huge number of games (it would end up having all told 24,000 titles).  As mentioned, no-one really knew what people would use it for – it was designed more to teach people to program and to experiment, than as a games machine for instance (other of its quirks included limited sound and graphics capability - sound was handled in an in-built speaker using the BEEP command and graphical sprites could only be in one colour).

The computer came with a manual which explained the Basic programming language, and there were also a few simple programs for you to type in and  try out – you can find a copy of this book online here.

In both magazines and books, you could get listings of programs that you could enter yourself, and “write your own game”.  The books were in my opinion far better, because instead of just a program listing to copy, it explained as you went along how the different sections and logic pieces work.  You learned something - especially how to copy and imitate!  [The most sincerest form of flattery]

What remained constant for both magazine and book program listings was that nerve wracking moment when you entered the RUN command.  No program worked first time!  There was almost always a transposition error.  But sometimes the listing was actually wrong, and contained a typo.  Oh, I was learning some important basics there in the fallibility of the software creation process.

And once working, there were many tweaks to be made.  Once you had a working game, there was a lot of fun to be had customising it.  Though sometimes those tweaks were made when you weren't looking – I remember we had a “Space Colony Management” game where you could allocate resources to food production, life support or manufacturing.  Me and my brother, ruthless capitalists that we were (in games), would sometimes “let it ride” by setting food production to zero for a couple of turns to maximise manufacturing.  Until one game, where we did this,to find there was a civilian uprising and we were executed as traitors to the people.  Well that was new!  Seems my father took exception to how we ran things, and modified the game to make us less ruthless capitalists, and teach us a valuable lesson about socialism.  It's a shame the Ceaușescus didn't play my dad's modified game ...

The process of getting a program to work was a difficult one.  There was no instruction manual for working through the problems that were thrown at you – although obviously if an error code was thrown up, yes indeed you could look THAT up.  However the more problems you encountered, the more you got the knack of recognising them and resolving them.

Here is the typical basic program you’d cut your teeth on.  It would come up with a random angle, and you’d enter a value to be told you’d either gone too far, too short or spot on.

10 REM "Artillery game"

20 CLS

30 LET a=lNT (RND*90)

40 INPUT "What angle to fire your artillery? (0-90) ",b

50 REM "Remember this was the 80s ..."

60 IF a=b THEN PRINT "Enemy tank explodes. Girls in bikinis thank you for saving their village!": STOP

70 IF a<b THEN GO SUB 100

80 IF a>b THEN GO SUB 200

90 GO TO 40

100 PRINT "Shot goes too far"

110 RETURN

200 PRINT "Short falls short"

210 RETURN

Obviously with the game ending, this would have been a precursor to the Red Alert series!

Even though this would work, it would have oddities.  If you entered text, it would typically crash trying to interpret it - it expected a number, and treated what your provided as such.  However if I remember correctly, if you entered “a” at the command line, “a” would be interpreted as the variable “a”, which means if you type it, you've automatically won!

Using it as well, you’d find of course that you could enter anything, not just angles between 0 and 90.  Common modifications to the above program would be,

• adding a count of the number of tries
• scan any input from the user, and not count if less than 0, bigger than 90 or contains none numeric.
• replace variables “a” and “b” with meaningful names like “target_val” and “user_input” for maintainability

Making changes contained risks of breaking what you had – you might cause a bad loop (one you'd never get out of).  You might just forget something, so for instance had instead of the line,

30 LET a=lNT (RND*90)

You had done,

30 LET a=(RND*90)

You would have ended with setting a number between 0 and 90 (just as you wanted)… except instead of this being an integer number, it would have been a floating point number.  This would have played a bit like this,

Guess a number between 0 and 90?

> 56

Too High!

Guess a number between 0 and 90?

> 55

Too Low!

Guess a number between 0 and 90?

> 55.56782

Sorry you failed.  The correct answer was 55.5678210234857

[Basically programmers, never try and compare if two floating point numbers are the same – they very rarely are to the level of accuracy a computer will insist on by default]

ZX Spectrum basic was really a very primitive language compared to what we now know as programming languages.  There were concepts I never really got used to like GOSUB commands (a form of function), all your data was considered global, if you had your computer upgraded you had all of 48k of memory (check today to see how much you can get with that).  However everyone was programming and giving it a go, customising what they could, seeing what you could achieve.  It was an exciting time to play with the technology.

I remember coming home with maths homework in 1983, and using a quick program to loop through solutions until it gave an answer using a stepping algorithm (though I didn’t even know what the term algorithm was, it just seemed intuitive and logical).  I remember producing programs over the years to simulate Browian motion, simple harmonic motion, falling objects etc.  It could be a powerful tool used like that.

But most of all, and setting me up for the future, I appreciate the apprenticeship of “what can go wrong” with programs.  Typing the command RUN always was an unsettling and exciting feeling, sometimes you’d just get exasperated with “What’s wrong now?”, "6 Number too big?  Really?".

Here’s a list of the dreaded error codes from a Spectrum fan site.

0 OK, 0:1

1 NEXT without FOR, 0:1

2 Variable not found, 0:1

3 Subscript wrong, 0:1

4 Out of memory, 0:1

5 Out of screen, 0:1

6 Number too big, 0:1

7 RETURN without GOSUB, 0:1

8 End of file, 0:1

9 STOP statement, 0:1

A Invalid argument, 0:1

B Integer out of range, 0:1

C Nonsense in BASIC, 0:1

D BREAK – CONT repeats, 0:1

E Out of DATA, 0:1

F Invalid file name, 0:1

G No room for line, 0:1

H STOP in INPUT, 0:1

I FOR without NEXT, 0:1

J Invalid I/O device, 0:1

K Invalid colour, 0:1

L BREAK into program, 0:1

M RAMTOP no good, 0:1

N Statement lost, 0:1

O Invalid stream, 0:1

P FN without DEF, 0:1

Q Parameter error, 0:1

R Tape loading error, 0:1

Over the years, stumbling over these codes, and fixing the problems beneath helped to develop an understanding of the ways software can go wrong.  

Years later I’d learn the word “heuristic” at James Bach’s Rapid Software Testing course which would better explain what had been going on.  I’d developed certain “rules of thumb” based on my experience using my own software, I’d gained knowledge of methods and experience where software just plain broke down.

Examples of those devious methods to break things included using

• using out of range numbers
• using nonsense numbers (such as decimal numbers where integers expected)
• using text instead of numbers
• guiding a graphical element off the screen

In fact look through those Spectrum error codes again, and you should be able to have a good guess at methods you could trigger half of those.  Oh yes, our languages might be more sophisticated, and our computers about a million times more powerful, but there is the same potential to cause those same fundamental errors listed above!

A few of the testers in my team are looking at understanding the basics of programming, and I'm encouraging them to.  Don’t get me wrong, I don’t really feel testers need to be able to code, but at the same time I believe it’s useful to have experience of writing code – not only to see how you break an idea into something deliverable as a series of statements, but primarily it’s the experience of having code fail on you, to understand how you investigated, debugged and fixed.  This allows us to have more empathy for the developers when they have to address any issue we find, and allows us to focus on what information will be useful to them.  But primarily it allows us to see how small divergences in code can manifest themselves when we use software.  Understanding that helps to drive understanding that provokes constructive ideas for tests.

In the end when we go hunting for problems in software as testers, yes indeed we tend to make sure it works out of the box in a manner consistent with expectations - the save button saves, the open button opens etc.  But also we tend to do a “greatest hits” mashup of our experience in testing – things we've seen go wrong before, things we've heard go wrong for others before, add a splash of imagination and then filter according to key values of the project to find the “it’d hurt if this screwed up” points.

For myself it would be not until 1996 that I’d learn another computer language beyond BASIC, or about concepts such as either data encapsulation or those all important subroutines and functions.  That learning would involve unlearning some of what I’d already learned.  But in terms of testing … the groundwork had been prepared.

Me and my beloved ZX Spectrum, circa 1983 ...