3 ms·

Quantify it. That's all most managers understand. Customer X wants the product in 12 weeks or they're going with a competing product. Customer X may be spendin

by 16s 16y ago

Quantify it. That's all most managers understand. Customer X wants the product in 12 weeks or they're going with a competing product. Customer X may be spending 6 or 7 figures with us over the next 5 years in upfront costs and ongoing maintenance and support fees. You may be saying, "It'll just take 6 months (24 weeks) to re-write this from scratch and do it right" (managers are used to hearing programmers say this sort of thing). For the most part, managers don't care about "doing it right" from a technical perspective, they only care about the bottom line. How is doing it right going to make more money (especially if we loose customer X in the process???) Also, be careful when making this suggestion. Many programmers who suggest this are simply uncomfortable with other people's code. They can write stuff from scratch themselves, but can't maintain or extend code they've not written (that's always a bad sign). And to make matters worse, they always use the argument "stuff I did not write is horrible".

dicarsio 16y ago
That's not the case, as there is another project in the same company with very good codebase made by one team, however, the one written by another team, sucks :-)
- 16s 16y ago
  Another risk... has a re-write been brought-up before and shot down? Did everyone agree (reluctantly) to make the best of it and continue with the code base? If that happened and you bring this up again, it may not end well. Management may see it as you undermining the project, not "being on board", etc. So unless you feel really compelled to do this, and you can do a good, objective quantification (here is why a re-write will make us more money) as why it must be done, don't bring it up. Also, telling mgt that a whole team in the company produces bad code may not be in your interest and it certainly won't make that team your friend going forward.
  - dicarsio 16y ago
    The code was written by outsourced people. And yes - another developer already talked about a rewrite, but it was postponed. Thing is, if we postpone and add lots of features, it will cost more to do it later! We can always rewrite portions of it, and make it more stable, but I truly believe in a rewrite - while the project is "young". Another factor is the lack of budget in the project =/

by 16s 16y ago

dicarsio 16y ago

That's not the case, as there is another project in the same company with very good codebase made by one team, however, the one written by another team, sucks :-)

16s 16y ago
Another risk... has a re-write been brought-up before and shot down? Did everyone agree (reluctantly) to make the best of it and continue with the code base? If that happened and you bring this up again, it may not end well. Management may see it as you undermining the project, not "being on board", etc. So unless you feel really compelled to do this, and you can do a good, objective quantification (here is why a re-write will make us more money) as why it must be done, don't bring it up. Also, telling mgt that a whole team in the company produces bad code may not be in your interest and it certainly won't make that team your friend going forward.
- dicarsio 16y ago
  The code was written by outsourced people. And yes - another developer already talked about a rewrite, but it was postponed. Thing is, if we postpone and add lots of features, it will cost more to do it later! We can always rewrite portions of it, and make it more stable, but I truly believe in a rewrite - while the project is "young". Another factor is the lack of budget in the project =/