So the value of your work was -19 programmer years, the cost to clean up after you're gone.
Was the code that bad?
This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.
Was the code that bad?
This is why we don't pay for productivity. It can't be measured, and the principal -agent problem looms large.
Most of these styles of rewrites I've seen over the years are grossly wasteful and mostly motivated by ego and politics.
When I once saw something like this it was "We just got a whack load of investor dollars for hiring" coupled with a belief that moving to a PaaS, requiring a rewrite to support that new infrastructure, that was purportedly easy for inexperienced developers would allow them to hire literal high school students (some quite amazing, to be fair) on the cheap and thinking that more developers would equal more output.
The original product was built on Postgres, and when I questioned the move away it was explained to me that hiring someone who understood how to work with such systems (the PaaS provides a document database that indeed does make it really easy to get data into it) would cost four times more than the juniors they were hiring. Four juniors over one senior was considered a good tradeoff for the business.
And it probably was for the first month or two. The early work was pushed out much faster than a lone dev would have ever been able to. But it wasn't long before the technical choices started to fall short, in particular the document database not being suitable for the workload, which ground velocity to a halt once the easy work was done. Eventually the project shrunk down to a couple of senior devs that were hired to untangle the mess.
One time, the company split into two: One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.
I was able to refactor and improve the "bad" code without much trouble. I'm pretty sure the reason it was deemed so bad was because certain engineers didn't actually try to work with it. They got offended by it quickly and gave up.
The rewrite failed btw - when I left, they were about to rewrite the rewrite (they had recently hired a new CTO).
The "bad" code brought in millions of dollars. It might still be doing so lol.
I was pretty junior in my career when this happened. It taught me that most senior engineers are posers. That generalization has only been reinforced as I've gotten more experience.
My employer is doing this now. I'm on the maintenance side. I am not refactoring it quietly, yet. I am quietly supporting the rewrite team, although I won't get credit for it.
The 'bad' code makes us money today. The new code costs us money today. I doubt it will ever be better enough to pay for its own development. But that does not seem to matter. Mgmt wants to be like google. Mgmt wants a bigger org.
Not much I can do except to keep the money coming in today.
Started on the rewrite, noticed it wasn't gonna go anywhere, asked to switch to maintaining the money maker.
Didn't need to refactor much: the code quality was VASTLY superior than the new system. However I not-so-silently worked on a redesign.
After four years not working there, the old system is still running full steam. The new one was shelved.
As others have pointed out, just like in software, we have to be cognizant of the career risk of hitching one's wagon to the product that's going out the door.