6 ms·

Even though the code you are interacting with appears awful, you may want to reconsider the rewrite strategy. This post may be helpful: https://www.joelonsoftwa

Even though the code you are interacting with appears awful, you may want to reconsider the rewrite strategy. This post may be helpful: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Consider rewriting only a handful of small parts that are causing problems critical to the success of the product, and making small improvements to the rest of it as needed over time.

avgDev 7y ago
This is impossible in my case, the source code is outdated. We do not have the source code of the project, which we run in production. The dev lost it. I have tried working with the source code but it has many bugs and it appears to be two years out of date. This leaves us with an application only in its current state with no way of making any changes. I may be able to extract pieces of information, reuse some stored procedures and so on.
- bluGill 7y ago
  At least you have something. You need to tell your boss that all features in the last 2 years need to be rewritten from scratch, with no lessons learned to speed up the effort, but that is still faster than starting over (particularly if the boss can say some things didn't turn out useful).
  - avgDev 7y ago
    Would you take this approach even if the framework is outdated? Part of rewrite is to switch to a newer framework and make general improvements in maintainability, reliability and speed.
    - bluGill 7y ago
      Yes. A framework is a detail, the business logic shouldn't care. Even if the framework is tied in I'd keep using it while moving newer stuff to something else. I've been in big rewrites to change the framework and everything else, on hindsight I believe I could have done an in-place refactor of everything to the new framework and been working the whole time, at less cost. That isn't hypothetical, in the above rewrite we took one part that was considered too essential to wait brought it in, wrapped it, and used the new framework. It was working much sooner than the other code. It still isn't completely re-written - but it doesn't need to be as the core business logic is known to work.
    - kolinko 7y ago
      Yes. By the way - „Working effectively with legacy code”. https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe... If you start from scratch you may bump into the same edge cases that the original writers bumped into, and end up with a code that is not much better than the original - even in the original is 2 years out of date. I’m sure there were cases when writing from scratch was a good call, but I don’t remember hearing about it.
      - avgDev 7y ago
        I guess if I do rewrite, I shall write about it as I go. If I fail it will make for a good story.
        adanto6840 7y ago
        I'd emphasize that failure on a project like this may not be what you'd traditionally have in mind when thinking 'that project failed', though it happens and it could be that bad in the absolute worst case. The issue is primarily that of the reward versus cost -- especially the opportunity cost. When the system is rewritten, will the business have increased revenue or decreased cost? Will it do so significantly, surpassing at least the cost to rewrite (salaries, etc) -- that's the absolute minimum bar, but then you have to consider the opportunity cost which is the real concern: If you had instead spent the same amount time adding new features, implementing an A/B test suite to increase conversions, improving marketing capabilities, retention mailers, or really any other activity that could positively impact the company business metrics -- would the impact be better than the impact of the rewrite? In most cases the customers (internal or external) don't really know or care how good/bad the underlying code is, as long as the product serves their needs. When that's true, even partially, the value of 'rewrite' almost never exceeds the opportunity cost alone, let alone the absolute cost (and that's to say nothing of the risks).
- ma2rten 7y ago
  If it's language that has byte-code like java or .net you might be able to decompile the production binary.
  - dllthomas 7y ago
    Even if it's not, decompilation might be useful. What I'd try is decompiling both the running version and the build of the available source code, and see if the diff is informative.
    - ma2rten 7y ago
      Last time I checked x86 decompilers were not that useful. They were producing code that is not compilable, often completely failing on more complex, translating code compiler boilerplate into code. This was a while ago so maybe things improved since then.
      - dllthomas 7y ago
        The goal here is some window into "what changed". For that, we don't need "compilable", and boilerplate won't be an issue provided it's stable (by no means guaranteed, to be sure). If I had to bet at even odds, I'd bet against it being useful. But the win is potentially large and the effort isn't.
  - avgDev 7y ago
    Good suggestion. I have decompiled the version in production. I will admit that reading it, is extremely frustrating as there are no objects and fields are named field1, field2, field3.
    - Drdrdrq 7y ago
      Still, you can compile + decompile the code you have, and compare that to decompiled production app. This might allow you to apply any cganges back to the code. Btw, it's not a dev who lost the code, it's the company and inadequate development process. It should never have been the single dev's responsibility to make backups.
- scarejunba 7y ago
  Slightly relatedly, we bundle our source code into our deployable artifact along with the revision. A bit silly and it increases the artifact size, but it's just another layer in the Docker image and so it's not that painful.
kl4m 7y ago
Another viewpoint: https://john-millikin.com/sre-school/no-haunted-forests https://john-millikin.com/sre-school/no-haunted-forests
hinkley 7y ago
At the end of the day, GP is claiming zero confidence on being able to maintain this piece of code. It's come out of their mouth as "I want to rewrite this" but what it means is "I think it would be less painful to rewrite in a way I can support than to bumble around like an idiot for 3 years in this one." There are a lot of things you can do with that input but you really have to acknowledge that there's a pretty big problem here, and some empathy is going to be part of our path out of this mess.
knightofmars 7y ago
Don't take the Joel On Software article as gospel (not saying that anyone is). There are other models out there as well: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22 https://medium.com/@herbcaudill/lessons-from-6-software-rewr...

avgDev 7y ago

This is impossible in my case, the source code is outdated. We do not have the source code of the project, which we run in production. The dev lost it. I have tried working with the source code but it has many bugs and it appears to be two years out of date. This leaves us with an application only in its current state with no way of making any changes. I may be able to extract pieces of information, reuse some stored procedures and so on.

bluGill 7y ago
At least you have something. You need to tell your boss that all features in the last 2 years need to be rewritten from scratch, with no lessons learned to speed up the effort, but that is still faster than starting over (particularly if the boss can say some things didn't turn out useful).
- avgDev 7y ago
  Would you take this approach even if the framework is outdated? Part of rewrite is to switch to a newer framework and make general improvements in maintainability, reliability and speed.
  - bluGill 7y ago
    Yes. A framework is a detail, the business logic shouldn't care. Even if the framework is tied in I'd keep using it while moving newer stuff to something else. I've been in big rewrites to change the framework and everything else, on hindsight I believe I could have done an in-place refactor of everything to the new framework and been working the whole time, at less cost. That isn't hypothetical, in the above rewrite we took one part that was considered too essential to wait brought it in, wrapped it, and used the new framework. It was working much sooner than the other code. It still isn't completely re-written - but it doesn't need to be as the core business logic is known to work.
  - kolinko 7y ago
    Yes. By the way - „Working effectively with legacy code”. https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe... If you start from scratch you may bump into the same edge cases that the original writers bumped into, and end up with a code that is not much better than the original - even in the original is 2 years out of date. I’m sure there were cases when writing from scratch was a good call, but I don’t remember hearing about it.
    - avgDev 7y ago
      I guess if I do rewrite, I shall write about it as I go. If I fail it will make for a good story.
      - adanto6840 7y ago
        I'd emphasize that failure on a project like this may not be what you'd traditionally have in mind when thinking 'that project failed', though it happens and it could be that bad in the absolute worst case. The issue is primarily that of the reward versus cost -- especially the opportunity cost. When the system is rewritten, will the business have increased revenue or decreased cost? Will it do so significantly, surpassing at least the cost to rewrite (salaries, etc) -- that's the absolute minimum bar, but then you have to consider the opportunity cost which is the real concern: If you had instead spent the same amount time adding new features, implementing an A/B test suite to increase conversions, improving marketing capabilities, retention mailers, or really any other activity that could positively impact the company business metrics -- would the impact be better than the impact of the rewrite? In most cases the customers (internal or external) don't really know or care how good/bad the underlying code is, as long as the product serves their needs. When that's true, even partially, the value of 'rewrite' almost never exceeds the opportunity cost alone, let alone the absolute cost (and that's to say nothing of the risks).
ma2rten 7y ago
If it's language that has byte-code like java or .net you might be able to decompile the production binary.
- dllthomas 7y ago
  Even if it's not, decompilation might be useful. What I'd try is decompiling both the running version and the build of the available source code, and see if the diff is informative.
  - ma2rten 7y ago
    Last time I checked x86 decompilers were not that useful. They were producing code that is not compilable, often completely failing on more complex, translating code compiler boilerplate into code. This was a while ago so maybe things improved since then.
    - dllthomas 7y ago
      The goal here is some window into "what changed". For that, we don't need "compilable", and boilerplate won't be an issue provided it's stable (by no means guaranteed, to be sure). If I had to bet at even odds, I'd bet against it being useful. But the win is potentially large and the effort isn't.
- avgDev 7y ago
  Good suggestion. I have decompiled the version in production. I will admit that reading it, is extremely frustrating as there are no objects and fields are named field1, field2, field3.
  - Drdrdrq 7y ago
    Still, you can compile + decompile the code you have, and compare that to decompiled production app. This might allow you to apply any cganges back to the code. Btw, it's not a dev who lost the code, it's the company and inadequate development process. It should never have been the single dev's responsibility to make backups.
scarejunba 7y ago
Slightly relatedly, we bundle our source code into our deployable artifact along with the revision. A bit silly and it increases the artifact size, but it's just another layer in the Docker image and so it's not that painful.

kl4m 7y ago

Another viewpoint: https://john-millikin.com/sre-school/no-haunted-forests https://john-millikin.com/sre-school/no-haunted-forests

hinkley 7y ago

At the end of the day, GP is claiming zero confidence on being able to maintain this piece of code. It's come out of their mouth as "I want to rewrite this" but what it means is "I think it would be less painful to rewrite in a way I can support than to bumble around like an idiot for 3 years in this one." There are a lot of things you can do with that input but you really have to acknowledge that there's a pretty big problem here, and some empathy is going to be part of our path out of this mess.

knightofmars 7y ago

Don't take the Joel On Software article as gospel (not saying that anyone is). There are other models out there as well: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22 https://medium.com/@herbcaudill/lessons-from-6-software-rewr...