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.
I have used a git subtree, and while I kinda hate it. I still think it was the right call given the constraints.
This is not a reply because I don’t want to argue with the take that brought it to mind.
If, for some reason, you want to use git subtree, think very carefully about doing so. Reasons follow.
Security misconfigurations can have far-reaching consequences beyond just cyberattacks. Faisal Parkar explores the various types of misconfigurations, their potential impacts, and how they can hinder business operations.
@pkw can I send you patches or something to https://git.sr.ht/~j9000/gui1/tree etc? Do you think we can use :package-inferred-system to make a LISPUSERS style monorepo like
lispusers/intro/gui/eg1.lisp
lispusers/intro/this/the-other.lisp
lispusers/integrated-sub-package/all.lisp
all as a heavily integrated community repo / ASDF system ?
@screwtape I'm looking at options for free public hosting.
Sourcehut seems the best. The guy that made it is an open source proponent.
The only downside of sourcehut is that you can't give access to a repo to other accounts through the web ui.
I'm guessing the paid option might allow that, and I wouldn't mind spending $20/year to get that.
Github seems to work fine, and i just created a free account with no CC. But it's MS :(
SQLite uses Fossil. The article doesn’t compare Git to Fossil, but instead explains why Fossil is better suited to them (and it brings nice improvement ideas for Git…).
I talk relatively frequency about how the size of the configuration space influences the practical utility of a tool (not here, I guess, but in my actual life).
My frequent target is ClearCase. People have made cases for it being the best SCM system for certain use-cases, but specifying what you want to get can be a full-on document.
On the other hand, Git is relatively simple (yeah, I know). The configuration space is smaller. #scm#git
They both have configurations that are at best better left unused and at worst start a death spiral of your whole SCM system. You can store large, frequently changing binaries in Git without LFS. You can do whatever my employer does with ClearCase and choke your server every time someone wants to look up a tag or branch. #ClearCase#git#scm