> 1. The codebase in question may be well beyond the line where any sane person would touch it, seriously.
> 2. Individuals experienced with the codebase, its structure, implementation, technology stack might be not available (think cobol).
There are people that reverse engineer binaries, find a place they can use a buffer overflow to insert a jump and then “program” by jumping around to different parts of the existing compiled code.
Your legacy cobol spaghetti code isn’t impossible to understand—-get better or better motivated engineers.
> 3. Refactoring or incremental rewrite is a process that has to be planned and managed s.t. current product/codebase structure. Oftencase it is this very structure, which demands the full rewrite -- because of it being too convoluted to allow refactoring to take place.
It does take extensive, often tedious effort, but there’s no such thing as too convoluted. A giant ball of tangled string can be pulled apart one knot at a time.
> 4. You might want to do a rewrite to refresh the tech. stack -- language, design, frameworks -- it is ok to do so.
> 7. You learn a lot in the process.
It probably is very true that a rewrite is often better for the resumes of employees. But employment is a fiduciary relationship. By cashing that paycheck you’ve agreed to put the company’s interests before your own. And rewrites kill companies.
When someone new comes in and within six months of starting starts pushing for a rewrite he should be fired and a hard look should be taken at what went wrong with the hiring process.
> 2. Individuals experienced with the codebase, its structure, implementation, technology stack might be not available (think cobol).
There are people that reverse engineer binaries, find a place they can use a buffer overflow to insert a jump and then “program” by jumping around to different parts of the existing compiled code.
Your legacy cobol spaghetti code isn’t impossible to understand—-get better or better motivated engineers.
> 3. Refactoring or incremental rewrite is a process that has to be planned and managed s.t. current product/codebase structure. Oftencase it is this very structure, which demands the full rewrite -- because of it being too convoluted to allow refactoring to take place.
It does take extensive, often tedious effort, but there’s no such thing as too convoluted. A giant ball of tangled string can be pulled apart one knot at a time.
> 4. You might want to do a rewrite to refresh the tech. stack -- language, design, frameworks -- it is ok to do so.
> 7. You learn a lot in the process.
It probably is very true that a rewrite is often better for the resumes of employees. But employment is a fiduciary relationship. By cashing that paycheck you’ve agreed to put the company’s interests before your own. And rewrites kill companies.
When someone new comes in and within six months of starting starts pushing for a rewrite he should be fired and a hard look should be taken at what went wrong with the hiring process.