In Vernor Vinge's book A Deepness in the Sky, humanity is spread out around the stars with only subluminal technology. Interstellar ships are very old and mix many technologies from different systems and civilizations.
They touch on the fact that computer systems have evolved for so long that nobody really knows most of the code anymore. They just use it and build on top of it.
One particular character has been traveling and in stasis so long that he is probably one of the oldest humans alive. A systems engineer of old. It turns out to be a big advantage to know the workings and vulnerabilities of his time because he can use them in the future when everyone else is building many layers on top of that and have no way of knowing exactly what he's doing.
There are two kinds of "nobody knows": "Nobody knows how to make room temperature semiconductors" and "Nobody knows why my washing machine failed"
In the former case, it's a genuine mystery that can be only solved by very smart people and modern science. In the latter, it's the lack of interest - sure, for $$$ a knowledgeable engineer will take the washing machine apart and figure out the exact defect, but no one is going to pay this, they'll just throw the washing machine away and get a new one.
The historical software knowledge is definitely the latter. It is eminently possible to dig into any part of software and eventually get a full understanding of this part. But most of the time, it's way cheaper and more practical to shrug and ignore the problem, or maybe add yet another layer to compensate.
Unless, for example, you invested billions into trains that run on Windows 3.11 and retrofitting all of them with a modern control system is prohibitively expensive. Which means the second type of knowledge becomes as irreplaceable as the first one.
I guess you mean "room-temperature superconductors"; if you don't, I submit you and your laptop can come out of the walk-in freezer now. It'll still work. ;)
There's also the classic, "Nobody knows how to make a pencil."
That kind of "nobody knows" is about the complexity of many large interconnected systems, and the deep wells of knowledge, theory, and history in each of the various domains.
I argue it's different from your washing machine type because the domains of computing are vast. Sure, you can dive in and figure some things out when necessary, but you can do that with pencil production too.
Agreed, there's a difference between "nobody has the time or money to care" and "no human mind has the capacity to hold the whole model at one time."
I was fortunate to get a computer and electrical engineering education that ran the gamut from making basic organic semiconductor structures in the lab and up the pyramid through logic gates, adders, a custom processor on an FPGA, writing a custom RTOS, patching the Linux kernel, and writing a userspace application.
There are no black boxes anywhere on that stack - someone somewhere knows or knew how it worked - but the last time that some systems engineer could claim comprehensive understanding of the stack was probably no later than the early 80s.
Individually, one can build broad competence, comprehension, and a career at some height in the pyramid, and can have limited comprehension of things directly above and below your zone, but the whole pyramid is superhuman.
You can figure out _a_ way to make a pencil, but it may not be as efficient or clever as they did it the first time. Or it might be a lot more practical with modern abilities that were impossible at the time of the first pencil.
If you started today, you might not use graphite, or wood. That's ok for pencils. But it might mean we've forgotten a technique they used for making pencils that's also useful for tiny gear shafts. But we don't use it for gear shafts anymore because somebody invented the Swiss lithoscropy process.
There is a library called `pyasn1`, the author passed away and there are some challenges, such as intimidatingly long error messages that are not easy to interpret, or counter-intuitive behaviour of some of the functions in its API.
Do you have any tips for approaching this with the few resources that are available?
"Nobody knows how to operate this 40 year old kubernetes cluster anymore". Some of you will go billing thousands per hour rewriting legacy Helm manifests for antiquated banking infrastructure.
This reminds of Asimov's awful "The Feeling of Power" where in the future mankind has forgotten how to do basic math and someone has rediscovered it to the astonishment of the people in power who now intend to use it to their advantage in war.
I hate that short story because of how silly it is. I get the point that it's trying to make, but it's packaged in such an absurdly unrealistic way that it loses all impact.
This reminds of Asimov's story where in the future mankind has forgotten how food tastes, and are having a computer-designed-flavours competition, and someone has rediscovered growing plants in soil makes delicious garlic to the astonishment of the judges, who are later horrified and disgusted when they learn the truth about what he fed them.
As someone who is separately both a programmer and an archeologist, I love the concept and the books. The real skills aren't always as far apart as you'd think either. I once spent a week deconstructing hardware to figure out what assembly language a project was written in. The assembly was only documented in a TRM in a dusty filing cabinet written before I was born. Once I could read the assembly I could read the source code and work my way up the stack to start answering the actual questions I had.
The nice thing with software is that everyone gets to be an archaeologist in short order; ~6 months is more than enough...
- Howdy! there's a bug!
- Okie, lookie!
*dig dig dig, stares at line 47*
- Oh my, this horsemanure could not have possibly worked, ever! What kind of damaged wetware wrote this?!
$ git blame
- Oh.
For sure, I imagine "software archaeology" will become a field of its own in the future. It reminds me of GitHub's Arctic Code Vault project, a snapshot of all public repositories as of 2020-02-02, meant to last for at least a thousand years.
I wonder what future humans will make of it, digging through such a massive amount of good, bad, and terrible code. Much of it probably won't run without serious effort.
Reminds me of a character in one of Alastair Reynolds novels who is a software archaeologist. I think they're in Tau Ceti, but anyway. The character has a specialty in digging through code that's hundreds of years old.
I think we're already dealing with this. My uncle is in his 60's and maintains old truck shipping software in COBOL. Btw there are job openings in old tech like this, for those that are interested. Happy to provide introductions.
But the basic problem stands, the left-pad issue.
We still deride this choice. Junior engineers without supervision hap-hazardly installing dependencies. But over the course of decades and generations of developers we still "sum to zero", where most software will rely on some number of unknown dependencies.
Say in 2100 an update needs to be issued. You push it through whatever is managing npm dependencies at the time. Meanwhile there is a solar system of dependent devices that need security updates. There could be trillions of dependent devices and any number of of independent intermediary caches that may or may not be recently updated. I can't event imagine what that dependency tree would look like.
Unfortunately knowing humanity and it's gatekeeping mechanisms he'd be near-unemployable. 'Oh you don't have XYZ framework experience? GTFO'
Also it's frustrating working in such conditions where you have to dig through framework code to get to where it matters. It feels like your time is wasted.
Indeed so. The highest-paid devs I personally know earn their living working with old COBOL code. It's highly paid simply because there aren't that many expert COBOL programmers around anymore.
In a prior job I had, we developed enterprise software aimed at large corporations. We had to support several old mainframes that don't actually exist anymore outside of museums -- but these companies ran emulators of the mainframes solely to continue to use the software they'd been using for decades. Nobody at those companies even has the source for that software, let alone know how it really works. It just works and they can't justify the expense of reworking their entire system just to get rid of it.
>It's highly paid simply because there aren't that many expert COBOL programmers around anymore.
They're highly paid not because they're part of a short supply of COLOB devs, but because they have COBOL experience and the battle scars to know how to solve production issues that those new to Cobol might not know about, but which the old timers saw several times already in their careers and know how to fix
If you start learning Cobol now to cash in on the this market, as a Cobol junior you won't be remotely as valuable as those Cobol graybeards with battle scars, which is why nobody's pivoting to Cobol.
I don’t think this is as mutually exclusive as you imply.
Good COBOL programmers are expensive because they’re rare, and the only way to become a good COBOL programmer is to spend a decent fraction of your education and/or career working with it. That doesn’t happen organically anymore for any significant fraction or junior devs.
>Yes, exactly. If you can find a way to get good enough to do it, you're guaranteed a great income.
You can't replicate years or decades of Cobol project experience to "get good at it", out of thin air by doing some side projects at home. No amount of individual self study can prepare you for industry specific cruft and issues you've never encountered. If it were that accessible, a lot of people would do it.
> they have COBOL experience and the battle scars to know how to solve production issues that those new to Cobol might not know about, but which the old timers saw several times already in their careers and know how to fix
Right, this is what I meant by "expert COBOL programmers".
>>Indeed so. The highest-paid devs I personally know earn their living working with old COBOL code. It's highly paid simply because there aren't that many expert COBOL programmers around anymore.
Heh - my backup retirement plan :-) Hell, COBOL paid really well during Y2K just add 2 characters to the date field :-P
It's like physics, right? When you understand the deeper layers of what you're working with, you understand what it's built on it makes you much more powerful.
For what it's worth, while the first two are set in the same universe, you can read them in either order. The third one is a definite sequel, and imo, the weakest of the three.
Gregory Benford made a similar statement about technology, where humans are in constant war with AI and often don't know how the tech they use work. IIRC there was a spaceship in Great Sky River[0] that could only be operated by humans because they did the tutorials. (Humanity's lack of knowledge was less a permanent regression and more a side-effect of constantly fighting, and losing, the war against the machines. Hard to study and learn when you're fighting all the time).
Yes Pham was considerably among the best talent due to the time spent training and diving deeper into the layers of abstractions while other were in stasis while drifting between the stars. That would later prove to become a superior advantage.
This is among my most favorite books and not just because it’s about a long time soldier software developer like myself.
They touch on the fact that computer systems have evolved for so long that nobody really knows most of the code anymore. They just use it and build on top of it.
One particular character has been traveling and in stasis so long that he is probably one of the oldest humans alive. A systems engineer of old. It turns out to be a big advantage to know the workings and vulnerabilities of his time because he can use them in the future when everyone else is building many layers on top of that and have no way of knowing exactly what he's doing.
Vernor had a point, I think.