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.
Add comment