4 ms·

> Don't redesign the database schema at the same time you are rewriting. Chances are, that's the problem though. You have to re-write because your design is b

> Don't redesign the database schema at the same time you are rewriting. Chances are, that's the problem though. You have to re-write because your design is bad enough that it's necessary. The only time you'd re-write without changing the design is when changing languages or platforms.

coldtea 7y ago
You could do a rewrite that takes into account the bad old database schema, but doesn't repeat the wrong code design choices based on it. Then, when that's ready and stable and working with the existing schema, it's way easier to do a refactor and adapt to the new schema too.
- wvenable 7y ago
  "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. " -- Fred Brooks, The Mythical Man-Month Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match.
  - dougk16 7y ago
    I've done several huge rewrites over my sordid career, and a strategy that works well is to abstract your bad data design behind a good one. This involves some kind of transformer layer between your bad data design spec and your abstracted better one. There's of course performance hits of some kind no matter what, but the hope is that they're worth the benefits of the cleaner code/architecture that the better data design spec affords. It's difficult I'll grant, much harder than abstracting simply bad code, but it's possible, and also makes it that much easier to replace the actual data design at some point in the future, and remove the transformer layer. Hope that makes sense!
    - wvenable 7y ago
      I've done the transformation layer in the small to keep components running during a re-write/refactor. Create a new structure and write some code (in the DB or otherwise) to make the new structure look like the old structure long enough to eventually replace that old code. I can't imagine doing that as an independent step towards a rewrite.
    - foobarian 7y ago
      Something similar I've seen is a bad data design that is embedded into a giant monolith, and has dependency tendrils everywhere. In that case it's worthwhile to factor out the logic (which includes cutting the dependencies) even leaving the schema intact. Once the problem layer is sequestered e.g. into its own microservice it is hopefully possible to release it on its own cycle much faster than the monolith, paving the way to improving the schema next.
  - paulddraper 7y ago
    Exactly. If I'm not refactoring the underlying data structures....the refactoring isn't a very interesting/difficult one at all
    - mcguire 7y ago
      That would kind of be the point.
      - deleted 7y ago
        [deleted]
  - coldtea 7y ago
    >Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match. Sure you can. You decouple your data structures from your schema with an abstraction layer, facade, etc.
mcguire 7y ago
Changing languages or platforms is a frequent cause for a rewrite. (Especially if the old one is Modperl 1.) On the other hand, if you need to refactor the database schema, don't rewrite the code. Just do the minimum modifications to keep the app working. Just don't do both at once.

coldtea 7y ago

You could do a rewrite that takes into account the bad old database schema, but doesn't repeat the wrong code design choices based on it. Then, when that's ready and stable and working with the existing schema, it's way easier to do a refactor and adapt to the new schema too.

wvenable 7y ago
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. " -- Fred Brooks, The Mythical Man-Month Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match.
- dougk16 7y ago
  I've done several huge rewrites over my sordid career, and a strategy that works well is to abstract your bad data design behind a good one. This involves some kind of transformer layer between your bad data design spec and your abstracted better one. There's of course performance hits of some kind no matter what, but the hope is that they're worth the benefits of the cleaner code/architecture that the better data design spec affords. It's difficult I'll grant, much harder than abstracting simply bad code, but it's possible, and also makes it that much easier to replace the actual data design at some point in the future, and remove the transformer layer. Hope that makes sense!
  - wvenable 7y ago
    I've done the transformation layer in the small to keep components running during a re-write/refactor. Create a new structure and write some code (in the DB or otherwise) to make the new structure look like the old structure long enough to eventually replace that old code. I can't imagine doing that as an independent step towards a rewrite.
  - foobarian 7y ago
    Something similar I've seen is a bad data design that is embedded into a giant monolith, and has dependency tendrils everywhere. In that case it's worthwhile to factor out the logic (which includes cutting the dependencies) even leaving the schema intact. Once the problem layer is sequestered e.g. into its own microservice it is hopefully possible to release it on its own cycle much faster than the monolith, paving the way to improving the schema next.
- paulddraper 7y ago
  Exactly. If I'm not refactoring the underlying data structures....the refactoring isn't a very interesting/difficult one at all
  - mcguire 7y ago
    That would kind of be the point.
    - deleted 7y ago
      [deleted]
- coldtea 7y ago
  >Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match. Sure you can. You decouple your data structures from your schema with an abstraction layer, facade, etc.

mcguire 7y ago

Changing languages or platforms is a frequent cause for a rewrite. (Especially if the old one is Modperl 1.) On the other hand, if you need to refactor the database schema, don't rewrite the code. Just do the minimum modifications to keep the app working. Just don't do both at once.