Comment by raizer88
6 hours ago
Every time something like this has been done on my company I follow up with the question: did anyone watched the code to see if the business logic is the same between the two versions? The answer is: but but but automated testing.
Followup question: did anyone read the automated test suite?
Silence.
The software rewrite is shelved.
> did anyone watched the code to see if the business logic is the same between the two versions?
Why not just ask the coding assistant?
also take the money saved on engineering and just run two systems in parallel for a year
Why do people doing a rewrite need to have read the tests?
If you have good test coverage, and the tests are reliable, then what's the problem?
If your engineering culture is bad already and you don't have good test coverage or they're flaky or whatever then that is different. If that is the case, it is probably from smart-ass attitudes like yours asking these "clever" rhetorical questions to derail people trying to improve things that led it to be like that. Do everyone a favour and keep your mouth shut and let people fix things.
The tests aren't reliable if the entire codebase was rewritten, including the tests, and then nobody read the tests.
Honest question: does that even remotely matter, or is it an outdated prior? All software has bugs.
The goal and objective is to deliver value for your user/customers; to the speed, reliability, and assurance requirements your market segment expects.
> to the speed, reliability, and assurance requirements your market segment expects.
I suspect that the average Cisco customer expects a bit more stability than $RANDOM_SAAS.
All software has bugs, but right now you have a legacy product in production that works, then you have a rewrite that nobody tested. Do you accepted the risk to yolo it?
Sometimes the risk is acceptable, sometimes it's not.
Yup. And its always garbage as result
Not if you have a good harness. Docs and tests first