4 ms·

Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. It's preferable to work in branches and rewrite

Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. It's preferable to work in branches and rewrite and refactor incrementally whenever possible, merging the new code in as things progress at convenient milestones. Then the history documents which functionalities in the old implementation became what files and lines in the new implementation. That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore.

klyrs 7y ago
> Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. That's the goal of this practice. Throw it all out and rewrite from scratch. > That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore. I'm talking about writing non-releases. The entire structure of the code, algorithms, data structures, API / CLI must not be preserved. Anything that stays constant between non-releases is either (a) a good idea or (b) a stone unturned. Rename variables, split and join modules, violently reorder function arguments... nothing is off-limits. After I've been through a few rounds of this, the first release should be entirely free of inessential warts (and maintenance is typically quite easy at this stage). After the first release, I'm a stickler about backwards-compatibility and my development pattern is closer to what you're suggesting. Among folks who know me, I've got a reputation for writing clean, optimized code. It isn't because I'm good at writing clean code; it's because I'm good at throwing away ugly code and I'm very reluctant to share code that doesn't meet the bar.
- Pamar 7y ago
  Sorry to sound cynical but... have you ever been introduced to the concept of "deadline"?
  - jodrellblank 7y ago
    I really want a way to filter out comments which boil down to a snarky “SOME people can’t do this”. Yes yes, have points, well done, but it’s a boring low effort class of comments that applies to nigh every single idea ever, and skips the interesting or important bits - in this case whether it produces better software or helps understand things - in favour of a cheap vote grab. “It’s not universally applicable” - no, nothing is. and you don’t sound cynical you sound like you’re trying to dismiss and status grab, like someone talking about the “out here in the real world”.
    - Pamar 7y ago
      I know it sounds snarky, and I am sorry (I even tried to apologize preventively, but I was in a hurry and this probably was taken as extra sarcasm on my part). Still, my point stands: I am not sure if this is really a matter of “SOME people can’t do this”, I suspect it is the other way around: “SOME people can do this... because they are working on free software, on their own personal project, on programs or systems that do not have any TTM aspect”. And it is not just a matter of "deadlines" either: if your code is part of some bigger system you may not have the chance to reimplement things from scratch not because you don't have time, but because you could impact someone else using your library/module/API. In other words, this approach is eminently laudable, but in my experience does not scale in most cases.
      - TeMPOraL 7y ago
        It does work somewhat under light pressure. Under high deadline pressure it obviously can't, but I'd argue that if a company is slave-driving programmers, code is going to be garbage and development will start slowing down due to accumulated technical debt. > if your code is part of some bigger system you may not have the chance to reimplement things from scratch not because you don't have time, but because you could impact someone else using your library/module/API. In this case, if your code is used by someone else, you can't do that. The trick is not releasing your code "out there" until after you've done several rewriting passes on it. In the cases I've done that in professional context, I worked on a feature branch. I would occasionally rebase it on top of master, to stay current with rest of the product, but nobody ever looked at my feature branch until I've done a few rounds on the code, declared it's ready for integration, and issued a merge request.
- newnewpdro 7y ago
  Sure, that's perfectly fine if it's for what amounts to entirely private development iterating on something nobody has ever seen. In my experience my MVPs often end up in production and that utopia of iterating in isolation is fairly short-lived.
  - ryanbrunner 7y ago
    That's true, but it's also something you have some degree of influence and control over. Don't allow prototypes or first awkward stabs to get into the hands of users without them being explicitly told this is a preview and their data will be destroyed.

klyrs 7y ago

> Except that way there's basically zero semantic continuity between the commits of the old program and rewrite. That's the goal of this practice. Throw it all out and rewrite from scratch. > That information can be very helpful when the rewrite breaks previously working functionality and customers are upset, especially if the rewrite authors aren't even around anymore. I'm talking about writing non-releases. The entire structure of the code, algorithms, data structures, API / CLI must not be preserved. Anything that stays constant between non-releases is either (a) a good idea or (b) a stone unturned. Rename variables, split and join modules, violently reorder function arguments... nothing is off-limits. After I've been through a few rounds of this, the first release should be entirely free of inessential warts (and maintenance is typically quite easy at this stage). After the first release, I'm a stickler about backwards-compatibility and my development pattern is closer to what you're suggesting. Among folks who know me, I've got a reputation for writing clean, optimized code. It isn't because I'm good at writing clean code; it's because I'm good at throwing away ugly code and I'm very reluctant to share code that doesn't meet the bar.

Pamar 7y ago
Sorry to sound cynical but... have you ever been introduced to the concept of "deadline"?
- jodrellblank 7y ago
  I really want a way to filter out comments which boil down to a snarky “SOME people can’t do this”. Yes yes, have points, well done, but it’s a boring low effort class of comments that applies to nigh every single idea ever, and skips the interesting or important bits - in this case whether it produces better software or helps understand things - in favour of a cheap vote grab. “It’s not universally applicable” - no, nothing is. and you don’t sound cynical you sound like you’re trying to dismiss and status grab, like someone talking about the “out here in the real world”.
  - Pamar 7y ago
    I know it sounds snarky, and I am sorry (I even tried to apologize preventively, but I was in a hurry and this probably was taken as extra sarcasm on my part). Still, my point stands: I am not sure if this is really a matter of “SOME people can’t do this”, I suspect it is the other way around: “SOME people can do this... because they are working on free software, on their own personal project, on programs or systems that do not have any TTM aspect”. And it is not just a matter of "deadlines" either: if your code is part of some bigger system you may not have the chance to reimplement things from scratch not because you don't have time, but because you could impact someone else using your library/module/API. In other words, this approach is eminently laudable, but in my experience does not scale in most cases.
    - TeMPOraL 7y ago
      It does work somewhat under light pressure. Under high deadline pressure it obviously can't, but I'd argue that if a company is slave-driving programmers, code is going to be garbage and development will start slowing down due to accumulated technical debt. > if your code is part of some bigger system you may not have the chance to reimplement things from scratch not because you don't have time, but because you could impact someone else using your library/module/API. In this case, if your code is used by someone else, you can't do that. The trick is not releasing your code "out there" until after you've done several rewriting passes on it. In the cases I've done that in professional context, I worked on a feature branch. I would occasionally rebase it on top of master, to stay current with rest of the product, but nobody ever looked at my feature branch until I've done a few rounds on the code, declared it's ready for integration, and issued a merge request.
newnewpdro 7y ago
Sure, that's perfectly fine if it's for what amounts to entirely private development iterating on something nobody has ever seen. In my experience my MVPs often end up in production and that utopia of iterating in isolation is fairly short-lived.
- ryanbrunner 7y ago
  That's true, but it's also something you have some degree of influence and control over. Don't allow prototypes or first awkward stabs to get into the hands of users without them being explicitly told this is a preview and their data will be destroyed.