this post was submitted on 17 Oct 2024
1368 points (98.9% liked)
RetroGaming
19795 readers
439 users here now
Vintage gaming community.
Rules:
- Be kind.
- No spam or soliciting for money.
- No racism or other bigotry allowed.
- Obviously nothing illegal.
If you see these please report them.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Programmers love to rewrite things, but it's often not a good idea, let alone good for a business. Old code can be ugly because it is covered with horrible leasons and compromises. A rewrite can be the right thing, but it's not to be taken lightly. It needs to be budgeted for, signed off on and carefully planned. The old system needs to stable enough to continue until the new system can replace it.
Okay, I'll tell you, in this situation, the code never really worked outside of the demo stage. It was written in bash+ansibel+terraform+puppet designed to use ssh from a docker container and run stages of the code on different servers. And some of it supposedly worked on his computer, but when it failed to run when he was not clicking the buttons, and I read through each part, I can promise you that it never worked
I didn't write broken code base because I didn't like the code, I meant that it didn't work
The whole point of docker is to solve the "work on my computer" by providing the developer hacked up OS with the app. (Rather than fixing it and dealing dependencies like a grown up)
Bit special for it to still be broken. If it flat out doesn't work, at all, then it may well be "sunk cost fallacy" to keep working on it. There is no universal answer, but there is a developer tendency to rewrite.
I'll consede that his point in using docker was to avoid the "it works on my computer" problem. It was literally one of his talking points in his handover meeting. But that is not the problem docker is trying to solve, and not it's strength.
Docker and similar container software makes many things very convenient, and has uses far outside it's originally intended usage.
And in this situation, when want stable package versions, and simpler uniform setup. And you don't have stable package versions because docker doesn't provide reproducible builds (and he didn't do the work work srojdn that), and it is not a simpler setup when you want to use the hosts ssh agent with ssh inside docker, which require different steps for different distros, Mac and Idk if windows would have worked? And sharing your ssh agent into the docker image is not stable either even if you set it up, it isn't sure to work the next reboot. And can be every difficult in some Linux distros due to permissions, etc.
Then I ended up putting it on a vm, that is already used for utilities. If I were to do it today, I would probsbly use nix, to actually run these programs that is very sensitive to program version changes in a stable reproducible environment that can run on any Linux distro, including in docker
But the program had many more issues, like editing yaml files by catting them and piping them into tac and piping into sed and then into tac again... And before you say you could do that just with one sed command, sure, but the sane solution is to use yq. Let's just say that was the tip of the iceberg
Oh and just have to note, claimed working features, but no way for that code the be executed, and when I actually tried to hook up this code, I can't believe its ever fully worked.
Sounds like you were given a mess alright.
Yes, thankfully, working conditions, both at my employer and in the customers office were (are) very nice, so all I can do now is laugh at the situation in hindsight.
In fact the worst part of working on this was that there were no deadlines, which makes every thing much harder with suspected adhd. Basically when things were working, and I wanted to make this better, I got new things to work on. But that is basically the customers perogative. I also like to pay for what I want and no more