10 ms·

When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was

When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive

runald 5y ago
Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.
- gefhfffh 5y ago
  When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.
  - sseagull 5y ago
    I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?” Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component? I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.
    - deleted 5y ago
      [deleted]
    - skohan 5y ago
      But how often would you actually have to rewrite an entire 10-20k LOC project at once? As you need to add functionality, you can opportunistically find ways to improve the codebase toward a better/more maintainable structure. I have several large codebases I work on which probably get totally rewritten every 18 months or 2 years, however incrementally. If you have a working project and you think you need to throw it all out and start from scratch probably it's worth a second thought.
    - hinkley 5y ago
      We always talk about time when the elephant in the room is energy. People say we don’t have “time” for that and someone else gets out a calendar and tries to disprove them. Followed by a bunch of backpedaling with other excuses and followed up with foot dragging. The second elephant in the room is job security. People who write baroque code are hard to fire. Nobody wants to invest energy in understanding their private little Bedlam.
  - runald 5y ago
    When starting, yes it's easy to replace code, even with a shitty design. If it had to take more than ten hundred thousands lines of code to realize that the design is wrong, then it means the author lacks enough awareness or foresight to plan ahead, and no amount of planning will fix that. Code should be replaced/rewritten if the earliest signs faulty design show up, which should be trivial if the code was and remains "disposable".
- mint2 5y ago
  Not having to pay for physical materials doesn’t mean there are no costs. Throwing hours, days, or weeks of focused work time out the window does not sound cost free to me or Whoever signs paychecks.
  - skohan 5y ago
    It's not throwing it out the window if it's an iteration toward a better solution. There's a reason nobody does waterfall anymore in software - up-front planning is less productive than rapid prototyping in most cases.
skohan 5y ago
Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they fit with just a little typing, that would be far and away preferable to committing to everything on paper before hand.
- gefhfffh 5y ago
  No, it is not cheap, generally. Example: Dendrite[0] was going to be a Rewrite of Synapse (which was a prototype which ended up going into production). The rewrite started more than 5 years ago, had lots of development breaks and it still is nowhere complete or close to replace a existing Synapse instance (which even today is ... Well ... suboptimal software). The current plans are to support and use both servers long term, because Synapse is already too widespread. I wouldn't call that cheap. [0]: https://github.com/matrix-org/dendrite https://github.com/matrix-org/dendrite
  - skohan 5y ago
    Well starting from scratch for a rewrite is generally a bad idea. I'm more a fan of incremental re-wrties. But I have code bases I have been working on for years with tens of thousands of lines where basically the entire thing gets rewritten ever 18 months or so, a bit at a time. Isn't your example proof of the benefit of pragmatic coding? Synapse is actually serving users right now. Dendrite sounds like a "better design" which is stuck in purgatory.
    - gefhfffh 5y ago
      They tried an incremental rewrite before. They failed, and started Dendrite. https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta
  - MrPatan 5y ago
    Survivor bias. You don't see all the perfectly designed codebases that never went anywhere. We only talk about legacy code because it's the one that pays the bills.

When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive

runald 5y ago

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.

gefhfffh 5y ago
When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.
- sseagull 5y ago
  I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?” Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component? I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.
  - deleted 5y ago
    [deleted]
  - skohan 5y ago
    But how often would you actually have to rewrite an entire 10-20k LOC project at once? As you need to add functionality, you can opportunistically find ways to improve the codebase toward a better/more maintainable structure. I have several large codebases I work on which probably get totally rewritten every 18 months or 2 years, however incrementally. If you have a working project and you think you need to throw it all out and start from scratch probably it's worth a second thought.
  - hinkley 5y ago
    We always talk about time when the elephant in the room is energy. People say we don’t have “time” for that and someone else gets out a calendar and tries to disprove them. Followed by a bunch of backpedaling with other excuses and followed up with foot dragging. The second elephant in the room is job security. People who write baroque code are hard to fire. Nobody wants to invest energy in understanding their private little Bedlam.
- runald 5y ago
  When starting, yes it's easy to replace code, even with a shitty design. If it had to take more than ten hundred thousands lines of code to realize that the design is wrong, then it means the author lacks enough awareness or foresight to plan ahead, and no amount of planning will fix that. Code should be replaced/rewritten if the earliest signs faulty design show up, which should be trivial if the code was and remains "disposable".
mint2 5y ago
Not having to pay for physical materials doesn’t mean there are no costs. Throwing hours, days, or weeks of focused work time out the window does not sound cost free to me or Whoever signs paychecks.
- skohan 5y ago
  It's not throwing it out the window if it's an iteration toward a better solution. There's a reason nobody does waterfall anymore in software - up-front planning is less productive than rapid prototyping in most cases.

skohan 5y ago

Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they fit with just a little typing, that would be far and away preferable to committing to everything on paper before hand.

gefhfffh 5y ago
No, it is not cheap, generally. Example: Dendrite[0] was going to be a Rewrite of Synapse (which was a prototype which ended up going into production). The rewrite started more than 5 years ago, had lots of development breaks and it still is nowhere complete or close to replace a existing Synapse instance (which even today is ... Well ... suboptimal software). The current plans are to support and use both servers long term, because Synapse is already too widespread. I wouldn't call that cheap. [0]: https://github.com/matrix-org/dendrite https://github.com/matrix-org/dendrite
- skohan 5y ago
  Well starting from scratch for a rewrite is generally a bad idea. I'm more a fan of incremental re-wrties. But I have code bases I have been working on for years with tens of thousands of lines where basically the entire thing gets rewritten ever 18 months or so, a bit at a time. Isn't your example proof of the benefit of pragmatic coding? Synapse is actually serving users right now. Dendrite sounds like a "better design" which is stuck in purgatory.
  - gefhfffh 5y ago
    They tried an incremental rewrite before. They failed, and started Dendrite. https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta
- MrPatan 5y ago
  Survivor bias. You don't see all the perfectly designed codebases that never went anywhere. We only talk about legacy code because it's the one that pays the bills.