7 ms·

Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base an

by avgDev 7y ago

Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite. I'm a relatively fresh SE, but I read books/research good practices because I'm trying to avoid major mistakes. Also, it is hard to explain to people who even know some code, how difficult it is to make what seems like a simple form. At this point I would refuse to work without time for unit testing/refactoring/research. Interestingly, few days ago I made a very minor change in app I developed straight out of school. App had 0 unit testing and minimal integration testing. It created a bug, because I allowed the specs to change weekly and I just coded it without thinking. Therefore, many lessons were learned that day.

adanto6840 7y ago
I've been a stakeholder in many a "rewrite is the only way forward" projects, though I have almost never actually advocated/voted for a "from-scratch" rewrite. I obviously say this having none of your domain-specific context -- so grain of salt -- but, in my experience, a total 'scratch' rewrite is rarely the right answer. Furthermore, it's often nearly impossible to even be able to ascertain the 'right answer' until you've gained significant exposure to both the application & the business needs; in my experience, you'll have a far better understanding & appreciation of the architecture after a year (or three) of exposure. At that point you are much better positioned to objectively understand the potential ROI (or lack thereof) on a rewrite project vs a more conservative but concerted effort towards incremental improvement over time. When mentoring developers on this general topic, one of the key things that I emphasize is that a functional application (even if substandard in architecture) is already solving a business need and often generating revenue/profit/positive ROI (as the case may be) for what was probably a "[re]write" project at some point in the past. Rewriting is a large undertaking with many unknowns & high costs, often higher than anticipated, and with no guarantees of reaching full functional parity in a given stated timeline. That results in difficult budgeting & ROI calculations (read: risky), and typically means the project itself is risky -- meaning the potential reward would need to be quite large to be worth it & offset the risks. I find that to rarely be the case when you already have a functional application, even if substandard. ;)
- dllthomas 7y ago
  Also keep in mind that often the existing application is the only real artifact you have capturing all of the complexity and corner cases your rewrite will have to deal with.
  - adanto6840 7y ago
    This is a very good point and it's probably far more common than it is given credit for. Sometimes you manage to catch some of these early on, but often they aren't caught until later in the process -- at which point the cost for the change (and the impact on budget/timeline, and potentially even the very architecture you set out to fix!) is drastically higher. I've seen it happen a number of times where the 'spec' seemed simple enough at commencement & throughout most of the project; then you'd have each department test & the reports would start coming in... and the result would inevitably be a multiplier on the project scope. Not from missing features mind you, but via the omission of 'complexity handling' / business logic which was documented -- but the code itself was the documentation, which isn't overly unusual (and IMO isn't even a particularly bad thing in many cases, though not all).
    - dllthomas 7y ago
      It's important that documentation be clear, discoverable, and up to date. Code-as-documentation is best-in-class at staying up to date, when it comes to documenting what a system does and how. Often the relevant pieces are very discoverable as you're going to make a change. For other goals, it's much less discoverable. Clarity depends on both how the software is written and who the audience is. Tests-as-documentation are arguably a special case of code-as-documentation. Outside of the case of well maintained tests-as-documentation, code-as-documentation often has a hard time expressing "why" and distinguishing between what has to be a certain way and what just happened to be that way. It also has some trouble expressing aspiration - "we've decided it should be this way, but it's not yet".
- zebraflask 7y ago
  Late to the thread, but just to chime in, briefly - I would agree unless the underlying platform has been deprecated. If we're talking about something in Java that could be better, in the abstract, but it still works, agreed: it might not be worth the effort to redo. Java isn't going anywhere, and versioning differences aren't always critical. If we're talking about deprecated front end frameworks that no longer have any LTS (Angular 1 comes to mind), moving over to a framework that does have LTS is a pretty smart move, if the code or app is that important and valuable.
drewolbrich 7y ago
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.
bluGill 7y ago
In my experience it takes months of looking at existing code before you see the good architecture under the superficial mess. In other words, work in the current code for at least a year before proposing a re-write. Source code older the the application doesn't mean much as a statement - any good process will build off a CI system which only takes old source code. The question is how different is the application the code generates from what exists, and what to do about differences. Massive methods are sometimes a sign that the good architecture missed something. Refactor them of course, but that doesn't mean the architecture is bad, just that it needs to change to fit current requirements. Documents/comments lie. Their value needs to be contrasted to the risk that they mislead you. I'm not saying you shouldn't have them, just not a much as you think. The problem with books and research is knowing when to apply them. The rules exist for good reason, but they are really guidelines not rules and sometimes they need to be broken. I'm considering that now in my application, the GUI depends on the business logic depends on the network at first glance, but looking closer I'm debating calling it fine because there is no business logic (network sends 5, business logic changes the type from int to mm/s, GUI displays 5 mm/s), so the complexity of making the business logic the thing everything depends on doesn't seem worth it. Maybe, I'm still trying to figure out where we go next, different guesses result in different optimal architectures: if we were really sure they wouldn't be guesses. I do agree that you shouldn't do anything without creating a test. Note that test is singular, don't try to create exhaustive tests, not only will it take too long, but you often will waste time on a test that is incidental to the implementation and not required. Create a test or two around something you want to change, and then make your change. You get some assurance you didn't break anything, if you were wrong and broke something, you at least get another test out of it.
- commandlinefan 7y ago
  > it takes months of looking at existing code All the while listening to management say, “this should be a one line change, why should it take more than a few hours?”
  - megablast 7y ago
    > this should be a one line change Oh great, you do it then.
megablast 7y ago
Sounds like you don't even have source control and a CI system.
- avgDev 7y ago
  You are correct. We have implemented source control and CI is the next obvious step, but those things were not in place 10 years ago when the application was developed.

by avgDev 7y ago

adanto6840 7y ago

I've been a stakeholder in many a "rewrite is the only way forward" projects, though I have almost never actually advocated/voted for a "from-scratch" rewrite. I obviously say this having none of your domain-specific context -- so grain of salt -- but, in my experience, a total 'scratch' rewrite is rarely the right answer. Furthermore, it's often nearly impossible to even be able to ascertain the 'right answer' until you've gained significant exposure to both the application & the business needs; in my experience, you'll have a far better understanding & appreciation of the architecture after a year (or three) of exposure. At that point you are much better positioned to objectively understand the potential ROI (or lack thereof) on a rewrite project vs a more conservative but concerted effort towards incremental improvement over time. When mentoring developers on this general topic, one of the key things that I emphasize is that a functional application (even if substandard in architecture) is already solving a business need and often generating revenue/profit/positive ROI (as the case may be) for what was probably a "[re]write" project at some point in the past. Rewriting is a large undertaking with many unknowns & high costs, often higher than anticipated, and with no guarantees of reaching full functional parity in a given stated timeline. That results in difficult budgeting & ROI calculations (read: risky), and typically means the project itself is risky -- meaning the potential reward would need to be quite large to be worth it & offset the risks. I find that to rarely be the case when you already have a functional application, even if substandard. ;)

dllthomas 7y ago
Also keep in mind that often the existing application is the only real artifact you have capturing all of the complexity and corner cases your rewrite will have to deal with.
- adanto6840 7y ago
  This is a very good point and it's probably far more common than it is given credit for. Sometimes you manage to catch some of these early on, but often they aren't caught until later in the process -- at which point the cost for the change (and the impact on budget/timeline, and potentially even the very architecture you set out to fix!) is drastically higher. I've seen it happen a number of times where the 'spec' seemed simple enough at commencement & throughout most of the project; then you'd have each department test & the reports would start coming in... and the result would inevitably be a multiplier on the project scope. Not from missing features mind you, but via the omission of 'complexity handling' / business logic which was documented -- but the code itself was the documentation, which isn't overly unusual (and IMO isn't even a particularly bad thing in many cases, though not all).
  - dllthomas 7y ago
    It's important that documentation be clear, discoverable, and up to date. Code-as-documentation is best-in-class at staying up to date, when it comes to documenting what a system does and how. Often the relevant pieces are very discoverable as you're going to make a change. For other goals, it's much less discoverable. Clarity depends on both how the software is written and who the audience is. Tests-as-documentation are arguably a special case of code-as-documentation. Outside of the case of well maintained tests-as-documentation, code-as-documentation often has a hard time expressing "why" and distinguishing between what has to be a certain way and what just happened to be that way. It also has some trouble expressing aspiration - "we've decided it should be this way, but it's not yet".
zebraflask 7y ago
Late to the thread, but just to chime in, briefly - I would agree unless the underlying platform has been deprecated. If we're talking about something in Java that could be better, in the abstract, but it still works, agreed: it might not be worth the effort to redo. Java isn't going anywhere, and versioning differences aren't always critical. If we're talking about deprecated front end frameworks that no longer have any LTS (Angular 1 comes to mind), moving over to a framework that does have LTS is a pretty smart move, if the code or app is that important and valuable.

drewolbrich 7y ago

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.

bluGill 7y ago

In my experience it takes months of looking at existing code before you see the good architecture under the superficial mess. In other words, work in the current code for at least a year before proposing a re-write. Source code older the the application doesn't mean much as a statement - any good process will build off a CI system which only takes old source code. The question is how different is the application the code generates from what exists, and what to do about differences. Massive methods are sometimes a sign that the good architecture missed something. Refactor them of course, but that doesn't mean the architecture is bad, just that it needs to change to fit current requirements. Documents/comments lie. Their value needs to be contrasted to the risk that they mislead you. I'm not saying you shouldn't have them, just not a much as you think. The problem with books and research is knowing when to apply them. The rules exist for good reason, but they are really guidelines not rules and sometimes they need to be broken. I'm considering that now in my application, the GUI depends on the business logic depends on the network at first glance, but looking closer I'm debating calling it fine because there is no business logic (network sends 5, business logic changes the type from int to mm/s, GUI displays 5 mm/s), so the complexity of making the business logic the thing everything depends on doesn't seem worth it. Maybe, I'm still trying to figure out where we go next, different guesses result in different optimal architectures: if we were really sure they wouldn't be guesses. I do agree that you shouldn't do anything without creating a test. Note that test is singular, don't try to create exhaustive tests, not only will it take too long, but you often will waste time on a test that is incidental to the implementation and not required. Create a test or two around something you want to change, and then make your change. You get some assurance you didn't break anything, if you were wrong and broke something, you at least get another test out of it.

commandlinefan 7y ago
> it takes months of looking at existing code All the while listening to management say, “this should be a one line change, why should it take more than a few hours?”
- megablast 7y ago
  > this should be a one line change Oh great, you do it then.

megablast 7y ago

Sounds like you don't even have source control and a CI system.

avgDev 7y ago
You are correct. We have implemented source control and CI is the next obvious step, but those things were not in place 10 years ago when the application was developed.