Hacker News new | ask | show | jobs
by layer8 843 days ago
Young devs won't believe it, but in the late 1990s, quite a number of software companies didn’t use source control at all. You just copied source files from/to a central location, and from time to time made a version_x.y.z copy of the source directory.
10 comments

I briefly worked for a company as recently as 2010 that didn't use source control at all, and didn't even do the "copy source files and version their file names" practice. Whenever they had to cut a release for an angry customer, they'd just find an engineer whose local copy actually built successfully, bump the version number in the code, build on his workstation, and release that. CEO didn't want his software engineers doing anything but writing code, including setting up source control, tooling, automation, tests, documentation...
this rings so painfully true for me. Except it was in 2008
Devs who haven't worked in industrial controls won't believe it, but the overwhelming majority of critical OT software still doesn't.
Because the lunatics who wrote the software turned it into a stupid contraption where the source files are mummified in xml and entombed in a zip file or some other proprietary binary container. PLC coding standards should be taken out back one by one and shot twice in the head.
As a Rockwell user, I can't agree more. But check out Copia Automation if you want to see an improvement to this problem.
What's OT?
Operational Technology.

It's basically IT but for industrial operations instead of commercial.

https://www.cisco.com/c/en/us/solutions/internet-of-things/w...

Thanks a lot!
Also production servers with /etc full of files appended with .bak, .bak.oct, .bak.incident, .bak.goddamnit2
I spend way too much time thinking back on how many things like this I've left around
You may be the only one. I wish the vendors I deal with spent even a nanosecond thinking about leaving stuff like that around. (Let alone multi-gigabyte copies of production databases, long-since obsoleted patches, etc.)
Or possibly RCS, which was kinda-OK for config files.

https://en.m.wikipedia.org/wiki/Revision_Control_System

I remember these times. But diff tools were still used in the 90s even when no scm available?
I see we worked at the same place.
True story, I was around in the 1990s so I was aware of those practices. Really advanced people would have a scheduled job running every hour (or on some basis) to keep an old copy just in case it was needed, usually a zip or tar file. So, a really crude versioning system.

Fast forward to 2008 and I am working on a project where we had an older person working on the project that would do this, use a scheduler to create a zip version. The younger guys I worked with said it was a crazy system and didn't understand why someone would do that. I told him it was an advanced practice just 10 years ago. Basically, people did a lot of stuff that would seem crazy now given the tools we have now.

> I told him it was an advanced practice just 10 years ago

This is a problem that can affect everyone, especially those working in more isolated areas. You come out with a great workflow in year X that's 5 years ahead of the industry, and it works, so you never progress.

Meanwhile the industry catches up, solving the problem another way, but you never learn because it's a step backwards, until it isn't, and then it's a massive learning curve.

You have to actively keep up with what the industry is doing and be willing to adopt the new ways of working even when they are in some ways a step backwards.

Goldman Sachs set up continuous integration (with automated testing etc) back in the late 1990s / early 2000s for the eco-system of their in-house language 'Slang'. Great system, way ahead of its time. (The language was also pretty neat for its time. You can tell that the people who came up with had a Lisp background. Think of it as a worse version of today's Python. And probably on par or ahead of 1990s Python.)

In any case, because of when they built that Continuous Integration system, it was all jerry-rigged on top of CVS. Problem is, they were still using that system for Slang 15 years later.

The last I heard companies using the naming convention version XXXXXX.extension where each X is a feature flag was in 2023. Bringing source control into practice was an controversial ideas. No, I didn't work there
Both of you are right. Right kind of right :).
Young devs won't believe it but that is still the case today in parts of my company
I remember this. It pushed the team I was on to adopt CVS (this is before SVN).
Same. This was in 2003.
Ha, that's still better than editing files directly on a shared drive.
My first job in 2012 was still working this way....