Retrocomputing software development process/methodologies

Question

_{This is a test question based on this meta post. If the question can be reworded to be more on-topic, please feel free to suggest improvements. This is an open ended question about software development on any retrocomputing platform.}

I'm curious to know how the software development process has changed since the dawn of the first personal computers. As a current software engineer, I use tools such as Jira and Pivotal Tracker, and we have methodologies like Agile and Scrum, but how were software projects managed for applications on retrocomputing platforms?

Answer 1

From a UK/Z80-based perspective:

• More than a few games were published using little more than a ZX Spectrum, a tape recorder, a copy of The Complete Spectrum ROM Disassembly borrowed from the public library and a taped copy of HiSoft Devpac. These, along with binders of handwritten notes and squared paper for graphics, and more cassette tapes than you can imagine made up the basic development system.

• A few years later, the slightly more affluent solo developer might splurge on a Tatung Einstein or Amstrad PCW and develop using HiSoft Devpac 80 (or Kuma's Zen, or Arnor's Maxam II) under CP/M. This allowed far faster assembly from disc, access to proper printers, and including assembly module files. The Einstein, though a dismal commercial flop, had a spectacularly good keyboard.

• The really well-off developer might have one of Andy Glaister's Programmers Development Systems. These were fast PCs or near-compatibles with parallel interface boards to each target computer.

Revision control? Regression analysis? Nah …

Answer 2

From the perspective of an independent Apple II programmer back in the mid-80s, I used a mix of AppleSoft BASIC and 6502 assembly language. My primary tooth cut was BBS software. One thing I'll say is that I had notebooks filled for every project.

Editing Code

AppleSoft BASIC's program editor (i.e. the interactive one that you entered when you powered on the machine) was fine, but didn't make it easy to edit programs. Sure, you could move the cursor around but when LISTed there was formatting which introduced gaps; it was actually faster in many cases to just retype the line. I eventually adopted a program called GPLE (Global Program Line Editor) from Beagle Bros. which made editing far easier (e.g. insert mode VS the editor's standard overstrike behavior).

For 6502 assembly, I used Merlin as an editor / assembler. It did a decent job and helped keep your tabs (as in column position of text) in order. Compile times were acceptable for the era.

Source Control

I didn't hear of source control until the 1990's, but I had two main practices:

1. Periodically snapshot your code by copying it to a floppy disk and labeling it (e.g. BBS v1.3 Oct 10, 1986).
2. If I was to make a change that I wasn't sure if I would keep, I would save a copy of the current state as another file so I could roll back if needed (e.g. LOGON.BAK)

I would imagine that source control was rare on the 8-bit home computers since in all honesty you really need a mass storage device to do such a thing; hard disks were very expensive back in those days (20MB Sider for the Apple II ran about $550 in 1986 or about $1200 in 2016 dollars).

Answer 3

In the early micro-computer days, most software was made by one person who may not have had much of a development process and probably no formal training in programming. Hackers by Steven Levy discusses such things. I'm thinking particularly of the chapter(s) on On-line Systems founded by Ken and Roberta Williams.

Answer 4

In my early days on the Apple II (82-83) I used the mini-assembler in the Integer BASIC ROMs to write an assembler of my own using AppleWriter 1 as the text editor. Source code backup was just straight copies of floppies. When ProDOS came out I moved over to the Apple Assembler that came with the SDK. I wrote a generic Zap the alien program, a half decent Asteriods clone and an implementation of Forth with that setup. Documentation was pretty good from Apple but a lot of the time I relied on references from Byte articles to find new books to borrow from the Library. The early Dr. Dobb’s got reprinted and bound and that was a gem to finally get from the Library. In the end I moved over to CP/M on the Apple with Turbo Pascal as my main environment eventually working for Borland in the UK doing technical support for a short period.

I tended to write my own games on the Apple II as I only knew one other kid with one and once we'd got the ripped off games swapped over new ones were far too expensive (£30 each rather than the £5 a spectrum game would have cost) I think the only originals I had was Suspended, The prisoner and Zaxxon.

Bigger outfits like Sinclair used a VAX for a shared development environment, I don't think there was much in the way of source control (VMS did have the ability to store earlier copies of files) I certainly know that some of the later spectrum ROM developers (I worked with some of them at a startup after Sinclair went bust) tended to use Ian Logans spectrum ROM book as it was better than the official source code.

On the source control front, SCCS was available on Unix boxes and I was excited to get a copy of RCS ported to MS-DOS by MKS sometime around 1987, I seem to remember using it on a BSD based Whitechapel MG-1 before that point.

The early versions of CVS were basically shell scripts wrapped around RCS (1993?) SourceSafe appeared a little earlier and was bought by Microsoft (1994) fairly quickly, I remember using it at one job before the Microsoft purchase.

Answer 5

The biggest ones thinking back to my time in the UK games business

• Downloading - You can now send software between machines over a network. That was an amazing improvement over downloading tape images, or in Amiga and ST days throwing floppy discs around the room. We had blue marks on the walls where people missed.
• Emulation - emulation was very limited and expensive so you had to debug the real thing. Fun when it tended to respond by resetting and then it took 3 minutes to download the next guess. We drank a lot more tea and got more breaks back then 8)
• Version control - really it didn't exist beyond dated and numbered disk backups
• Compatibility - everything reads the same format media. We had to fight incompatible tape formats, incompatible disks, wacky things like the Sinclair Microdrives - ever tried getting software onto a Sinclair QL off something else ?
• Self hosting development. That came in with the Amiga/ST/PC but was a nightmare (not impossible) earlier. So a lot of cross development happened on Trash80 boxes with floppies or CP/M.

It wasn't a very professional industry. In some ways that wasn't so important. Our largest projects we could track all the assets on a couple of sheets of paper. The number of people on the core parts of a project probably never exceeded five including art.

Answer 6

I can't speak specifically to 'personal computing', but from a 1970s/1980s minicomputer perspective, a few points. Since I believe your question is essentially about multiple programmers producing one product, I don't suppose the specifics of the hardware really matter; the only difference is that the project members shared the same computer.

1. If there was no formal 'source control', then individual programmers basically copied files in and out of staging directories. You were trusted to not screw up, and on the whole, you didn't.

2. There were usually nightly system backups.

3. Every now and then, when some functional goal had been achieved, a 'base level' was declared. This likely included full system build, regression tests, building new 'source disks' and 'source tapes', and if you were lucky, sending the latter to offsite storage in case the building burned down.

4. Project management was basically the same as today: someone needs to know what's going on, the overall state of the universe, and how we're tracking against schedule. The tools you use don't change that.

Answer 7

I started working in the computer industry in the mid to late 80's. Most of my work involved larger computers than micros and teams of up to 10 or more people working on bespoke projects.

At that time, we mostly followed some variation of the "waterfall method". Sometimes, if the customer asked for it, we would use a formalised version of the above like SSADM. The company I worked for adhered to the waterfall model fairly strictly, even though there were some severe problems with the way it was applied.

The waterfall system, for those unaware of what it is, breaks down a project into several different phases: requirements definition, functional specification, development, integration testing, system testing, acceptance testing, maintenance and support. Each phase is supposed to finish before the next one begins, although, in practice, there was always some overlap.

As for the tools, we worked with a variety of different hardware architectures and a variety of different operating systems. I probably worked with more hardware architectures and operating systems in the first five years of my career than in the subsequent 27 years.

The quality of the developer tools was variable. Some operating systems had source code control e.g. VMS, some didn't, so part of any project was to build some sort of source control system. Even the editing tools could be inadequate. If the OS supplied you with something as good as vi you were happy.

Answer 8

One thing not yet mentioned in the other answers is how much more we made and used printouts (for those of us lucky enough to have a printer). Viewing code on an 80×25 or, worse yet, 40×24 screen makes it difficult to get a higher-level sense of the program, quickly check other bits of code, and so on, and that many microcomputer editors of the day were rather poor just made that even worse. Now I regularly have open several windows of 60-70 lines or more for editing, another one for compiling and error messages, and yet more for documentation; back in the day this was done by printing out your entire program on a regular basis and marking it up as you went along, printing out the error messages from an assembly, and having lots of reference books and notebooks.

Last year I did a fairly detailed writeup of what it's like to go back to development on an Apple II using circa-1980 tools; this is what reminded me of the printout issue. It may have other interesting bits in it as well.