Spaghetti code is easier to write than maintain, and in doing software archaeology (yes, it’s a thing), I’ve encountered numerous reasons for it. Requirements creep is one of the largest reasons.
In fact, the first real software archaeology I did was explained, proudly, as being a product of someone walking in and telling the developer, “Wouldn’t it be nice if…”. Of course, nobody wrote anything down, and by the time I got to it the software was 25 years old and didn’t even have a brochure. People were still walking in and saying, “Wouldn’t it be nice if…”. Meanwhile, the company was required to follow standard software processes because it was required for contracts.
So I learned, from good teachers and a few bad ones, about Software Configuration Management, Software Quality Assurance, and Software Testing. There were reasons we did things a certain way. Our project configuration management contained everything needed to rewrite the software from scratch, including every single tool. I’d actually done a backup of a development pc after writing down the hardware specifications of the system and handed that in because quality assurance had to be able to take the same stuff and rebuild the same software so that it could be tested.
From scratch. And it had to pass the same tests. From scratch.
What I saw in other companies after that was never at that level, and on the surface it seemed ridiculous. However, any software engineer worth their weight in skittles has been screwed over by a platform changing underneath the code. Windows was infamous for it, though I did encounter it in an Apple shop as well. Your code hasn’t changed, but some update suddenly had you in the middle of bug city without even a flip flop. Microsoft has been notorious about that, with their version back in the day called DLL Hell. It’s just their (old) version of dependency hell.
I never had the problem with *nix systems, though when open source became popular and everyone started using that in their code, *nix systems started to get it too. People blamed the open source, but it was really 2 things that caused the problem.
(1) Bad Configuration Management (if it even existed!) and
(2) Taking the open source project for granted.
Open Source projects that are done voluntarily are completely outside the control of a company, but having an open dialog and even sending some money for pizzas and beer can avoid issues. Even with all of that, volunteers are fickle, so having in house expertise on projects becomes as important as how important the projects are to a company’s software. A company doesn’t really know this, though, when they don’t have software configuration management for their projects – so you end up with spaghetti projects, or as I call it, “Spaghetti Configuration Management”.
Toss in the developers that are copying and pasting from Stack Overflow, or now GPT, dash in employee turnover, where expertise is lost, and you get software entropy. Talking about software entropy causes the eyes of pointy haired bosses to roll to the back of their heads, so instead we talk about technical debt, because one thing businesses understand is debt.
Over the years, companies I worked for were at various stages of technical debt. It’s a real thing, and the startups that survived long enough to get to the point of technical debt were the worst because of the culture shift needed: Documenting things, tracking things, and making sure that the knowledge stayed within the company. I can say with good conscience that I left every company better off than when I left it, sometimes because of the company, sometimes despite the company.
Anyone know how to install version 18.19 of nodejs in an Ubuntu instance in Github Actions? apt-get can't find that version. #help#linux#ubuntu#nodejs#dependencyHell
Rant: today I wanted to prepare a simple NFT demo for high-schoolers. They should use a pre-created smart contract, add their images, and then deploy this on a test network.
finding some test-EHT was already difficult
some tutorials exist, so I tried to follow those
eth-brownie doesn't seem to be supported anymore and doesn't work on MacOSX (anymore?)
it's successor, eth-ape, doesn't work on MacOSX, neither
I tried devbox (nix), docker, compiling from source... Usually I think of myself of a good programmer. But dependency hell in Python is a level I'm really not used to.
Anybody got any idea how to do this in a simple way?
@doot when I looked into setting up a Mastodon single user instance the instruction described how to do it on Ubuntu or Debian.
So can anyone tell me why don't they get the relevant packages into the Debian/Ubuntu packaging systems so as well as simplifying installation running daily unattended updates would push any security fixes automatically?
Mastodon in Debian "seems stuck in Ruby #DependencyHell ..., and is likely to prove difficult to maintain in the long term unless upstream calms down a bit" per @Anarcat [1]
Maven Central and Gradle Plugin Portal should have never allowed to publish dependencies with not-fixed versions.
If you don't check your transitives carefully, something might sneak in. And you have non-reproducible builds. Which you only notice once something breaks.
Ok - https://matrix.infosec.exchange is alive! It requires an account on the mastodon instance at infosec.exchange. If there's a demand, I'll open general registrations