2 ms·
In software engineering, we only ever maintain processes, not artifacts. Software modularity when it exists is usually extremely coarse and rigid when compared
by boricj 2y ago
In software engineering, we only ever maintain processes, not artifacts. Software modularity when it exists is usually extremely coarse and rigid when compared to the malleability of electro-mechanical systems.
Got a bug to fix or a feature to implement on a program? Modify the source code, run the build system, use the newly built artifact and discard the old one. Lose this process and you're screwed because the tooling for modifying an extant program is still in the Dark Ages. It's not just about proprietary software that has reached its end of support, given enough time almost any source code tree will bitrot past the point where rebuilding it will require a major overhaul.
When you need to fix or customize a physical artifact like a coffee machine, you usually don't go inside the factory to change the blueprints and manufacture a new one. You just modify the one you have with standardized tools. It also doesn't matter how old the artifact is, even if it's decades out of production it can still usually be disassembled and put back together as if it was fresh out of the assembly line.
The more software bleeds into electro-mechanical systems, the less repairable, versatile and hackable they become.
- jiggawatts 2y agoThat's very insightful, and I just wish I had the ability to explain this to non-technical managers. "But it was working!" "Sure, 10 years ago, now I can't even find a version of Visual Studio that will install that can even open the project, let alone compile it."
- actionfromafar 2y agoAnd VS on an old laptop or Virtualbox might actually work, still. Good luck recreating some random services tangle from the year 2024 in 2034.
- jiggawatts 2y agoSince Visual Studio is Windows only, the straightforward solution that I used was to install an old version in a Hyper-V virtual machine. Then it's a multi-step process where the project is upgraded inside the VM with an ancient VS copy as "far as it'll go", then copied out to the external environment with VS 2022 that also has the 2016 and 2019 "Build Tools" installed. Then the projects can be upgraded to "current day". In some cases I just gave up and created new empty projects with identical names and GUIDs, then copy-pasted the code files across. It can be simpler and faster.