4 ms·

More than that, it assumes the 19 headcount decision was a good management decision. It obviously wasn't; regardless of how brilliant the OP is (I have my reser

More than that, it assumes the 19 headcount decision was a good management decision. It obviously wasn't; regardless of how brilliant the OP is (I have my reservations, just from the fact that the company opted to -rewrite- it rather than extend/build around it), you don't hire 19 people in one year to replace a piece of software written by one person. That reeks of "we need this replaced ASAP; get two teams of contractors working on it", without realizing that past a certain point adding people creates negative value.

analog31 4y ago
I've seen code so bad that it was declared to be a total loss after the original programmer was discharged.
- whateveracct 4y ago
  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.
randomdata 4y ago
> That reeks of "we need this replaced ASAP; get two teams of contractors working on it" 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.

analog31 4y ago

I've seen code so bad that it was declared to be a total loss after the original programmer was discharged.

whateveracct 4y ago
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.

randomdata 4y ago

> That reeks of "we need this replaced ASAP; get two teams of contractors working on it" 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.