5

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 I'm curious as to how software projects were managed for applications on retrocomputing platforms.

Are questions about software development methodologies for applications and retrocomputing platforms on-topic for main?

The question is now live on main: Retrocomputing Software Development Process/Methodologies

| |
  • 2
    I would consider questions about writing software for retrocomputers to be retrocomputing, not least because programming is required in order to use most of them! – wizzwizz4 Jul 2 '16 at 15:16
5

You're probably good with posting it here. I asked a question a while ago about coding forms which has a lot of up votes. It's not a very highly technical question, but I think it sets the stage for more complex questions about how "software" used to be written.

| |
4

This is a tricky one.

There has been a natural progression of coding methodologies since the "old" days, but the fact remains that these new methodologies would have worked back in the day if there was infrastructure to support it.

That is, software development methodologies and processes are primarily a social issue with a historical aspect, not necessarily related to specific retro technology. Just as our actual hardware and software tools had to mature, and did in their own unique ways, so did the social coding tools like design and test methodologies. But I'm not convinced that one follows the other, but rather are somewhat co-dependent.

As an example, OO and functional coding is not some sort of prerequisite for test-first or Agile conventions. Similarly, the fact that a particular system (say) uses an 8-bit addressed chip with extended 16-bit registers does not preclude TDD practices when coding on it.

These things are, essentially, orthogonal to each other.

War-stories about how coders in the olden days organized themselves are interesting, of course, but I'm not sure it makes for good SE content.

| |
  • 1
    Agreed, except for the last paragraph. Although it is arguably more opinion based, this question feels well aligned with many of the pure hardware questions here. I don't think the social and historical aspects covered by this sort of question will detract from the community here - there is little risk of diluting the quality of the content. – Sean Houlihane Jul 9 '16 at 9:42
2

Well, my first "real world" job was probably in the style you're asking about, although there were some "personal" computers (my high school had a PDP-8 with 1 terminal, essentially making it one) at the time, most development was still in earlier styles. My job was as a part-time programmer for a large department store. Their Payroll, Billing and many other things ran on a single batch mainframe.

You can get some interesting insights on software development in those days from the book The Mythical Man Month (which I recommend to everyone in computing, although some of the insights are a little dated, it's a fun read and a lot is still relevant).

So, the way I did "software development" was I started sitting at my desk (nothing higher tech than a desk lamp evident in a room with 6 programmers sitting at desks). Possibly starting with a flow chart or similar if it was going to be complex but usually not. I would then code the program by writing (in pencil) on coding forms which were basically lined sheets with 80 columns marked off across them. I would probably do some editing as I went (erasing small bits to rewrite or even just crossing out whole sections). When I had something, I then put the forms in the inbox in the keypunch room.

Then, after some time (usually only a couple of hours, but since I was still in HS and working part-time, it was more often when I next came into the office), the deck of punched cards would arrive at my desk. I would usually check some of the more critical cards and then write up a "run form" (a single sheet with places to write important things like who the result should go back to, but it did have a check box to request the operators let the programmer know it was running in case that was needed). It also described any setup requirements (like existing input tapes in their racks, or example tapes attached to the request, and also blank tapes for output and instructions either to recycle them or include them with the output). The run form was then wrapped around the deck (and any tapes, etc that were needed) and put in a large bin in the keypunch room that was between the programmers office and the computer room.

Then, after some time, the operators would have some free time on the machine and come out and check the bin of programmer's requests and pick one to run. After they ran it, any printouts would be added, and they would add notes on the run sheet (like what error message it crashed with), and put it in the next bin.

Usually the first couple of times you submitted a program it wouldn't even compile. But part of the printout would be a complete listing with errors (the listing from the compiler was much easier to read than the cards :-). So, you figured out what you needed to change, and if it was only a small amount you would enter it yourself using keypunch in the keypunch room for programmers, if it required a lot of input I might write up some new coding forms and have one of the keypunchers enter it. You would sort the new cards into the deck (usually manually, but the cards were numbered so you could use the sorter if available) and went back to writing up a new run form and submitting it again.

Then, after some time (you might notice a trend here :-) an iteration would actually compile and attempt to run. Then the real fun begins! The printout you get back ends with a core dump, a printout of the actual contents of the memory at the time of the failure. You get to figure out from the compiler listing where in the dump all of your data and code is, so you can figure out what it was working on at the time and why the variables were messed up the way they were. This, of course leads to another round of new cards to update the program deck and another run sheet, etc.

Then, after some time, you'd get a run that doesn't crash and actually has output. But, you're not finished, you have to cross check the printout yourself and then get the appropriate department manager to accept it. Either of which might result in another update/run/debug series.

In those days, programs that were so simple that today I would knock them off in an afternoon, might take a whole month to get right.

My, this became a lot more rambling than I expected when I started. But, back then things took a long time, so I guess the explanation is long as a consequence.

| |
  • 5
    This answer isn't meta enough... It's not a bad answer, but it's not an answer to this meta question, which was intended to discuss if one can ask this type of question in the first place. It actually might be a good fit for my question about coding forms, which I used as an example for why we should allow this type of question. – Laurel Jul 3 '16 at 2:49
  • 1
    This is a great anecdote, thank you! When I post on main this will be a great answer. – JAL Jul 3 '16 at 2:51
  • 1
    Yeah, OK. I started to write it as a short example to end with "so it seems a reasonable question", and then I was distracted and got into the writing and forgot that I was intending a short thing. By the time I remembered that I was in Meta rather than the site, I decided I'd finish it so I'd have all that work saved somewhere, and I can copy over when the question shows up on the main site... – MAP Jul 3 '16 at 3:30
  • Finally got around to posting this question on main, feel free to post your answer there: retrocomputing.stackexchange.com/q/1349/621 – JAL Aug 10 '16 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .