I do have that in mind – have not forgotten! I remember when a 20 MB disk drive was about the size of a washing machine (plus another cabinet for the controller) and cost around $50K (in 1970s dollars). And yes, RAM back in the day was assembled by hand with ferrite cores with little wires running through them, most of such assembly taking place in Asia, mostly in what became colloquially known as the Hong Kong Core House. 
My mother we l worked for IBM in… Probably the late 50s. Among other things, she was on a team that tested the newly invented machine code: three letters instead of a string of 1s and 0s. It was a massive success. It turns out that it’s vastly easier to remember three letters than bits.
Anyway, she wrote some y2k compliant code as an exercise, because it was an interesting challenge. But
- everyone assumed the stuff they were then would be supplanted within a year or three by new code
- RAM was massively expensive, and quite a lot of programmer time was spent making things work with slightly lower memory needs.
- processing time was also expensive, and making code ever-so-slightly faster was also an important skill.
She was shocked when she visited in the late 90s and found that some code she’d written was still being used. That was totally not what anyone has expected when she wrote it.
(Her y2k compliant code did not simply store 4 digits for the year of every date, that would have been crazy and a huge waste of money.)
I worked for a company that made ferrite read/write heads. All hand wound by young women in South Korea and Malaysia.
The machine you’re thinking of was likely the IBM 650, the first commercially successful digital computer. At the time, core memory was almost impossibly expensive, so the main memory of the 650 was what was then known as drum memory – a small, very rapidly rotating cylinder. In today’s terms, the drum had a capacity of approximately 20 KB.
The “three letter” codes you’re describing would have been the early assembly language for the 650, which was called SOAP – “Symbolic Optimizing Assembly Program”. SOAP translated the symbolic instructions into actual machine code and loaded it on the drum. Why “Optimizing”? Because part of the program’s task was to place the machine instructions on the drum in such a way that in the time it took to execute any given instruction, the next one would come flying by the read head just in time, thus minimizing latency due to drum rotation.
I have to say, though I may be an old dog, that the IBM 650 was way before my time. I’ve never even seen one, though I do have (somewhere) a SOAP manual, a wonderful piece of computer history!
80% of the work in any IT system is the input and display. It’s the “easy” part, which is why it’s only 80% of the effort.
Australia implemented a new tax system in July 2000. One of our clients was in Y2K lockdown, imposed by head office in another country, so they only had 6 months to implement a major system upgrade. They didn’t make it.
Moore’s Law really had nothing to do with mechanical disk drives, though arguably did apply to SSDs. But more to the point, when you’re talking about memory capacity, there’s a fundamental difference between main memory and secondary storage. Main memory content is transient and only has to be big enough to contain the currently running processes. Secondary (i.e.- disk) storage is cumulative.
It wouldn’t be hard to believe that “x” amount of main memory should be sufficient for any foreseeable future, while the needed capacity for secondary storage is potentially infinite. The only reason we “need” so much main memory today is that it’s cheap and software designers are lazy – they don’t need to worry about optimization, so they don’t. It’s true that we have far greater OS and application software functionality today than in the past, but the minimum demand for RAM is way out of proportion to that.
I didn’t say that it did. There was an analogous law (I think first published by Paul Frank) that had to do with the number of bits per square inch or something similar on magnetic media.
Reuse. In the silicon manufacturing world, they routinely reuse old numbers for new product. It’s still differentiated by date.
Again the problem is not the logical idea “reuse numbers”. It’s the practical problem of “every government and commercial computer system / program that uses SSNs needs to be rejiggered to account for the possibility of reuse.” That’s a much taller order than one company making their parts catalog app smart about part number reuse.
My spouse’s great-uncle and aunt had a joint account of some kind, under both their Social Security numbers. They both died years ago, childless, and that account is still sitting out there (now in the state’s unclaimed property office), and will be sitting there probably forever, because the value in the account isn’t enough to be worth the effort of getting all the heirs on the same page. (As I recall, they had between them fourteen siblings, all now deceased, and most or all of the next generation are likewise deceased, leaving something like seventy or eighty people in the current generation who are co-heirs to an account worth less than $5K.) The various unclaimed property offices probably have a lot of accounts where there either isn’t an heir at all or there are too many heirs, and they’d have to adjust their systems to account for reuses of SocSec numbers.
Every quarter I receive an automated email from the Health Savings Account provider my employer used to use about the HSA of a former employee in my position, deceased these ten years and counting. The HSA company thinks he’s still alive, and I can’t talk to them about his death because I’m not him or his authorized representative. Human Resources here won’t talk to them because they’re not the current HSA provider. His family ignored my attempts to forward the email to them. SocSec certainly knows about his death (his minor children received benefits) but MetLife is apparently going to keep him alive in their system.
For that matter, Social Security itself identified 18.9 million numberholders born in or before 1920 who as of December 2020 did not have death information recorded in the SSA Numident file (source). Most of these had not received any SocSec benefits since at least the 1970s, so are almost certainly long-deceased, but for various reasons their file never got updated. What should happen with their numbers?
Which means that there’s an additional date code or part number code affiliated with the serial number and effectively of part of the serial number. I was a manufacturing engineer for thirty years. You never ever reuse full serial numbers.
I just gave an example where a serial number gets reused, and it’s not a big deal. Sure, it’s best practice not to reuse serial numbers, but then systems rarely understand their scale when they’re conceived (looking at you Y2K bug).
There’s really no problem reusing numbers because the date is a non-optional additional identifier.
Perhaps we should be identified by something else, like genome sequence?
I think that was @hajario ‘s point: If you do reuse serial numbers, you have to also specify the date to avoid ambiguity. Which means the date is effectively part of the serial number because it always goes together with the other digits. Which means you really aren’t reusing the entirety of the number.
And more importantly, every system that uses the number now needs to be modified to use date+number. And for the ones that don’t already have that date on file, they need to go get it somehow. For people long dead.
Good luck getting a clean mistake-free database out of that.
What’s the other 80%?
The USA still hasn’t fully converted to 9-digit zip codes. So many places use the shorter less specific first 5 digits.
Bill Gates’ quote related to DOS -based programs (and was inaccurate even then, as some keeners started building massive spreadsheets and such using huge amounts of memory). But consider the amount of RAM needed to simply display a standard VGA screen of text (25x80 characters, characters for screen display generated on the fly) vs. Windows, where the entire graphics had to be stored (640x480x4 bits of colour), it was too complex to redraw on the fly every 1/30 sec. Plus, all the windows content had to be kept in code too - window this size, this location, this format of border contains this viewport onto the window’s content starting at this location, scroll slider is at this location on the side, the bottom, etc…
I don’t know if it’s actually that many places don’t have the extra four digits so much as lots of mail doesn’t use the extra four digits. My address has the extra digits - but most of my mail doesn’t include those digits. It’s really only bulk mailers that use them - they probably get a discount on postage because it makes sorting easier but when I get a letter from my insurance company or the dentist or anyone else I gave my address to, it will only be the five digits.
I think th other 80% is convincing the top brass that it is worth the high cost of replacing a functional system with a new one. Fortunately, Y2K hype eventually forced them. Banks and other institutions they were beholden to pretty much demanded proof of Y2K compliance.
The problem with any system is - it’s a lot easier to computerize a manual process, than to replace any working existing system with a new one.
As I mentioned, part of the problem was that incremental extra functions were added over time to an antiquated back end. When I started at my first programming job, they were in the process of replacing serial tape processing with database access. They did not write new programs. Where a program read a tape sequentially (sorted by employee number) they simply changed the code to query to a database in the same order; reading certain data in, then instead of wrting the update to a new tape, update fields on that same database. Read employee data, read timecards for that employee, write employee data with updated info on hours worked per day, and pay, etc. Where the in and outputs were sequential tape records, they were now in a database. Over time, more and more online access could update items in that database. But… the database still had 2-digit dates. Presumably when the system was first written in the early 70’s there was no concern about 1800’s birth years for employees. (It would be scarier if buried in the code it assumed any year older than 90 was 1890’s)
That was around 1980. There was never a need to re-write the entire employee payroll system (or the accounting, or ordering systems, inventory and sales, etc.) until Y2K came along. They actually started planning in the early 90’s.
As an example, when they had to switch payroll for some departements to the head office system, they discovered the database had been coded for employee names as alpha, meaning no apostrophes in names. Simply going through and changing that would have been a monumental task.
In the end, they replaced the old COBOL systems with purchased Enterprise Management and payroll systems, rather than write new ones in house. Funny thing, a lot of the consultants dealing with customization asked “why do you do things that way? Industry standard is this way.”
There are still a lot of computer systems that diverge from industry standards for security, often in horrible ways. Think of all of the times you hear about hackers getting a list of passwords to some site: That should be impossible, with proper security. And good, industry-standard security systems can be had cheaply (sometimes even free) and off-the-shelf.