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
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!
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.
