4 ms·

The way I would approach it is, to create a really simple table which, contains the pros of fixing the current code on one side and doing a rewrite on the other

The way I would approach it is, to create a really simple table which, contains the pros of fixing the current code on one side and doing a rewrite on the other. Then I would provide the benefits of doing both and then I'd present this to the person and say having, looked at our current code I believe that we should rewrite it because of X, Y and Z, in fact I'd even summarize this at the bottom of the table as well incase they want to take the table away and think about it.

dicarsio 16y ago
I guess I'll try that. The code is poorly written and with possible bugs in it, so I can show a lot of problems to prove my point.
- triviatise 16y ago
  Code that is working and in use is worth roughly 10x your imaginary code that doesnt exist. So unless you could prove to me that the savings or value is 10X the cost to rewrite I wouldnt do it. Can you be more specific about why the code is bad? There are a limited set of architectural reasons for which I would support a complete rewrite. They typically correspond to non-functional requirements: 1) scale - the system architecture simply cannot support scaling 2) reliability - the system architecture is built in such a way that the system often fails 3) multi language - the system needs to be modified to support multiple languages 4) security - the system needs to be modified to support a more robust security access model etc (there are many items like this) These things all touch every single bit of code and so could warrant a rewrite. Im skeptical of most other reasons. In most cases you can just modularize the most dangerous aspects and you will be fine.
  - dicarsio 16y ago
    One of the major problems within this project are poorly written, slow db queries, MVC is not correctly implemented (although using an MVC-based Framework, function names not intuitive. I can improve, refractor some aspects of the code, but the time that will took to fix it can be more than the time to recreate it in another framework. What do you think?
    - triviatise 16y ago
      for me the question is still, what problems is this causing? slow db queries can easily be isolated and unless they have done something like every write to the database creates an object which then gets converted to a sql transaction, function names can be fixed with global search and replace. Not sure what you mean by MVC is not correctly implemented
      - dicarsio 16y ago
        I mean that, model bits are inside controllers, for example :-)
    - jtheory 16y ago
      Poorly-written queries are very easy to refactor -- fix one query at a time, correct indexing strategy gradually, etc. Likewise, function names are ideal to refactor -- many IDEs will automate this for you. I don't know your situation, but this sounds to me more like framework envy (and I base this on experience... I've worked with projects on a lot of crappy and/or homegrown frameworks before). If you haven't actually done any major projects in the newer framework yet, that's a bad sign as well, I'm afraid. :) On a more positive note -- it might be possible to incrementally move to a new framework. It's harder if you want to switch languages/environments completely, but if not, it's probably quite feasible (switch over a feature at a time). If both frameworks can access the same session storage... that's likely the main tricky aspect.

dicarsio 16y ago

I guess I'll try that. The code is poorly written and with possible bugs in it, so I can show a lot of problems to prove my point.

triviatise 16y ago
Code that is working and in use is worth roughly 10x your imaginary code that doesnt exist. So unless you could prove to me that the savings or value is 10X the cost to rewrite I wouldnt do it. Can you be more specific about why the code is bad? There are a limited set of architectural reasons for which I would support a complete rewrite. They typically correspond to non-functional requirements: 1) scale - the system architecture simply cannot support scaling 2) reliability - the system architecture is built in such a way that the system often fails 3) multi language - the system needs to be modified to support multiple languages 4) security - the system needs to be modified to support a more robust security access model etc (there are many items like this) These things all touch every single bit of code and so could warrant a rewrite. Im skeptical of most other reasons. In most cases you can just modularize the most dangerous aspects and you will be fine.
- dicarsio 16y ago
  One of the major problems within this project are poorly written, slow db queries, MVC is not correctly implemented (although using an MVC-based Framework, function names not intuitive. I can improve, refractor some aspects of the code, but the time that will took to fix it can be more than the time to recreate it in another framework. What do you think?
  - triviatise 16y ago
    for me the question is still, what problems is this causing? slow db queries can easily be isolated and unless they have done something like every write to the database creates an object which then gets converted to a sql transaction, function names can be fixed with global search and replace. Not sure what you mean by MVC is not correctly implemented
    - dicarsio 16y ago
      I mean that, model bits are inside controllers, for example :-)
  - jtheory 16y ago
    Poorly-written queries are very easy to refactor -- fix one query at a time, correct indexing strategy gradually, etc. Likewise, function names are ideal to refactor -- many IDEs will automate this for you. I don't know your situation, but this sounds to me more like framework envy (and I base this on experience... I've worked with projects on a lot of crappy and/or homegrown frameworks before). If you haven't actually done any major projects in the newer framework yet, that's a bad sign as well, I'm afraid. :) On a more positive note -- it might be possible to incrementally move to a new framework. It's harder if you want to switch languages/environments completely, but if not, it's probably quite feasible (switch over a feature at a time). If both frameworks can access the same session storage... that's likely the main tricky aspect.