Like the classic, inherit a broken code base, and not being allowed by the owner to rewrite it from scratch. So you have to spend more time making each part work without the others working. Also before you are finished the customer says they have something else for you to do
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.
That’s when you start introducing modules that have the least impact on the legacy code base. Messaging is a good place to start, but building a new code next to the existing one and slowly refactoring whenever you got time to spare is at least a bearable way to go about it.
Shhhh you just described iterative development. Careful not to be pro agile, or the developers with no social skills will start attacking you for being a scrum master in disguise!
Like the classic, inherit a broken code base, and not being allowed by the owner to rewrite it from scratch. So you have to spend more time making each part work without the others working. Also before you are finished the customer says they have something else for you to do
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.
That’s when you start introducing modules that have the least impact on the legacy code base. Messaging is a good place to start, but building a new code next to the existing one and slowly refactoring whenever you got time to spare is at least a bearable way to go about it.
Shhhh you just described iterative development. Careful not to be pro agile, or the developers with no social skills will start attacking you for being a scrum master in disguise!
Fuck agile, or scrum, or whatever it is called. I just look at the issues and pick whatever I feel like doing. Kanban for life.