-1

I'm putting together a talk of the history of best practices in software development and we're trying to put together a bit of a timeline of how good practice has evolved.

This question talks about the history of Source Control and talks about how the first versions started to appear in the 80s but I'm hoping we can go further back.

I'm looking into the work done at Bletchley Park during WW2 and the machines Alan Turing and his team built to crack the German codes. These are widely considered to be some of the earliest modern day computers and used hardware switches and mechanical components rather than what we may recognise as software today.

However, these were the predecessors for the programs we create today and were every bit as complicated. Do we know what kind of change tracking practices (or what we know today as source control) was used while building and programming these incredible machines using the switches?

Liath
  • 3,406
  • 1
  • 21
  • 33
  • I'd be interested to get advice on how the question can be improved. Bletchley Park contained some of the earliest modern computers and their "software" was updated frequently in an attempt to crack german codes. Turing was a genius but I can't believe he simply plugged components in and hoped for the best! – Liath Apr 04 '18 at 12:45
  • 2
    In a maybe really obscure sense, I'm sure he used source control via pencil and paper. In other words, he kept track of changes by simply writing it down. I don't know if you could honestly call that source control in any real sense though. – Neil Apr 04 '18 at 12:46
  • 2
    I think this question would be better if it didn't focus so much on Turing and more on the history of source control. As I understand the program part of the computers in Blecthley Park was hardware, not software. The input was messages to decode and guesses to prime the calculation. Each set up with switches. – Bent Apr 04 '18 at 13:04
  • 4
    You're way off base in your estimates. Source code control was still unheard of in many workplaces in the **1990s**, let alone the 1940s. – Kilian Foth Apr 04 '18 at 13:14
  • 1
    Source control? Turing didn't even have *files!* – Mason Wheeler Apr 04 '18 at 13:17
  • 1
    Possible duplicate of [When was source control invented?](https://softwareengineering.stackexchange.com/questions/184695/when-was-source-control-invented) – Greg Burghardt Apr 04 '18 at 13:22
  • @Bent I've tried to reword to focus more on keeping track of the hardware and configuration (the bits we have in common) - after all, that's a major part of source control today! – Liath Apr 04 '18 at 13:25
  • 1
    You don't have to dig through historical documents to try to feel what it was like. Instead, you can live the reality, today. Get a job in a different engineering area other than software, e.g. mechanical design. Work in a regulated industry, such as implantable medical devices. Complicated, paper-based administrative change control systems are still alive and well in 2018. – whatsisname Apr 04 '18 at 15:58

3 Answers3

3

I do not know what you are really interested in, but remember that inputting code into a terminal is a modern thing.

When people first started to really write code (instead of hardwiring things), they wrote it on paper sheets and from there it was translated for the computer (punch cards were common). So your paper sheets give you a complete history of all programs, and your punch cards may also.

Turing, of course, was even before the time of freely computable machines.

J Fabian Meier
  • 513
  • 4
  • 17
  • Yeah - and then they'd obviously be able to replace the old versions of the sheets (unless bugs had eaten them) but I was under the impression that before that they were pure hardware so I wasn't sure... – Liath Apr 04 '18 at 12:55
2

Source control was not a thing, but you could say that there was an ad hoc source control, resulting from all the administration around the project. Read further though, because there's more to Source Control than that.

The word did not exist, even the concept didn't exist. And there would have been no way to rollback the work instantly like you could do nowadays with git, but there was probably lots of traceability in the documents, so that nothing would get lost or forged.

Keep in mind that the development iterations back then were much much slower.

There were several reasons:

  • Everything was handwritten or typed on paper, including schematics, etc.
  • It was war time, so there was a lot of formal validation going on, like the officer to whom the team was reporting to had to sign documents constantly.
  • Many peripheral tasks that were performed by specialized teams. There used to be rooms full of peope whose job was solely to perform complex calculations, fast. There were also people whose job was solely to punch cards.

All these documents had to go back and forth, and were constantly validated, and then archived. Formally, you may call that an embryo of source control, applied to a tiny team of like 10 people, tops. What I'm describing doesn't even accurately represent the daily work routine o Turing during WWII. What I'm describing is more of a 1960's NASA project.

"Modern", automated, dedicated source control is a billion lightyears away from that. If you're satisfied with such a lose definition of Source Control", then you could call anything source control. It wasn't even sources, only doodles and technical documents.

I would add that source control is not only meant to archive and rollback, but also to handle concurrent modifications. There were no such things in Turing's time, since his team and he were dispatching tasks after meetings gathering a handful of people.

jeancallisti
  • 136
  • 3
  • Exactly what I was looking for! Thanks for taking the time to answer what's turning out to be quite a controversial question... – Liath Apr 04 '18 at 13:31
  • 1
    What you are discussing are the typical documents of the waterfall software development lifecycle. As I stated in my answer, the closest analogy in Turings time would be a lab notebook (in fact lab notebooks are still in use today, though they are often on-line). With lab notebooks, concurrency is handled though 2 different people working on related projects and documented what they did in their notebooks. Someone has to go though and combine the 2 results, probably via a meeting. – Robert Baron Jul 10 '23 at 14:26
2

The closest thing would be lab/engineering notebooks. These notebook should have what was planned, what was done, what the result were and future plans.

These notebooks are considered legal documents and are commonly used in patent disputes.

They are not source control, though they serve an analogous function.

Robert Baron
  • 1,132
  • 7
  • 10