4 ms·

I've just as often see engineers claim code is a total loss and rewrite...without even trying to improve the existing code. One time, the company split into tw

I've just as often see engineers claim code is a total loss and rewrite...without even trying to improve the existing code. 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.

mring33621 4y ago
'One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.' 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.
- ratww 4y ago
  Also been there. 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.
- grayclhn 4y ago
  One piece of advice: make damn sure you get credit for supporting the rewrite.
analog31 4y ago
This is actually quite common in the hardware space. A hardware project can take a couple years, meanwhile the existing product has to be sustained. Also, a lot of stuff in a hardware product can become a total loss due to component obsolescence or the need to cram new / different features into a physical footprint. Even if it was a great design. 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.

mring33621 4y ago

'One skeleton crew to maintain the "bad" code in production, and everyone else was allocated to the rewrite.' 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.

ratww 4y ago
Also been there. 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.
grayclhn 4y ago
One piece of advice: make damn sure you get credit for supporting the rewrite.

analog31 4y ago

This is actually quite common in the hardware space. A hardware project can take a couple years, meanwhile the existing product has to be sustained. Also, a lot of stuff in a hardware product can become a total loss due to component obsolescence or the need to cram new / different features into a physical footprint. Even if it was a great design. 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.