The programmer with the messy program did what any sensible software engineer would have done in her shoes: Set aside the old software and built something useful, that did what was needed, using the full power of the company’s modern computers.
That’s… not at all how it works in the real world.
If you are lucky, you have a quality comprehensive regression test suite and you can redesign the code to pass every test, and then pray that the use cases not in the test suite don’t mess things up.
If you are less lucky, your test suite is neither comprehensive nor quality, and you have to wade through the test cases one by one to see which ones matter.
If you are in a situation most programmers are in, there is no regression test suite at all, and you have to reproduce the old program not just feature for feature, but also bug for bug, since your users are now relying on the old behavior. And that effort is comparable to what has been spent on that code so far by everyone who worked on it.
If you have some leverage on your users, you can tell them that if they want this new feature by the date they want and at a price they can afford, they have to accept a version 0.1 of the new Minimum Viable Product and wait for more features as you implement them, with the understanding that they will never get a clone of of the original product, and will have to adapt their processes to the new one.
If you have no leverage, you do what your predecessors did and very carefully add the new feature without breaking (or “fixing”) any of the old ones.
The story is from the 1990s. The character is actually my dad. It was a mid-sized actuarial firm. He started by writing a whole new program to do the function he needed the spaghetti-code laden crap to do. Then he added features here and there until he had just made a whole new program which was documented, easier to read, and functioning well. After awhile, he passed it to the other actuaries, and his work became the new software. But he never did use the old software.
I guess things are different now. As the person above also said, it’s impossible to ignore the super-system that a small system is embedded in. Additionally, I think some of his reasoning for outright refusal to use the old software was that he wasn’t comfortable that he wouldn’t be able to audit it, and he was signing off on yearly reports for the firm.
That’s… not at all how it works in the real world.
If you are lucky, you have a quality comprehensive regression test suite and you can redesign the code to pass every test, and then pray that the use cases not in the test suite don’t mess things up.
If you are less lucky, your test suite is neither comprehensive nor quality, and you have to wade through the test cases one by one to see which ones matter.
If you are in a situation most programmers are in, there is no regression test suite at all, and you have to reproduce the old program not just feature for feature, but also bug for bug, since your users are now relying on the old behavior. And that effort is comparable to what has been spent on that code so far by everyone who worked on it.
If you have some leverage on your users, you can tell them that if they want this new feature by the date they want and at a price they can afford, they have to accept a version 0.1 of the new Minimum Viable Product and wait for more features as you implement them, with the understanding that they will never get a clone of of the original product, and will have to adapt their processes to the new one.
If you have no leverage, you do what your predecessors did and very carefully add the new feature without breaking (or “fixing”) any of the old ones.
The story is from the 1990s. The character is actually my dad. It was a mid-sized actuarial firm. He started by writing a whole new program to do the function he needed the spaghetti-code laden crap to do. Then he added features here and there until he had just made a whole new program which was documented, easier to read, and functioning well. After awhile, he passed it to the other actuaries, and his work became the new software. But he never did use the old software.
I guess things are different now. As the person above also said, it’s impossible to ignore the super-system that a small system is embedded in. Additionally, I think some of his reasoning for outright refusal to use the old software was that he wasn’t comfortable that he wouldn’t be able to audit it, and he was signing off on yearly reports for the firm.