6 ms·

Regarding being 'unwilling to face the music', is it possible that you were only able to perform this refactor due to all the 'thrashing' that came before you?

Regarding being 'unwilling to face the music', is it possible that you were only able to perform this refactor due to all the 'thrashing' that came before you? Is it possible that the majority of commits leading up to your refactor were dealing with unforeseen complexities and addressing real bug fixes that you were able to conveniently take in and synthesize all at once? Refactoring too soon, before understanding the entire system (and all the possible changes/additions/issues that could arise) is probably worse (time-wise) than thrashing for a bit.

JoeAltmaier 6y ago
As I recall (and it was a long time ago) the history gave some insight into the complexity. But nobody had exhaustively enumerated all the cases. I remember the chart had more conditions that had ever been addressed.
- hinkley 6y ago
  You'd be surprised how few people look through commit history while bug fixing. There's a steady stream of people who don't understand why 'breaking' the commit history is a problem, and assume you have some sort of untreated OCD if you bother to even care.
  - potta_coffee 6y ago
    Commit history has saved my ass more times than I can count. Especially useful on a codebase that has churned through a lot of developers that you've never met.
    - hinkley 6y ago
      Yeah, including other people's bugs. Worked a few places where people would just give up on bugs well before I did, and less than half of that was perseverance. The first time I recall doing this was when a QA person came to me to complain that in the last handful of releases we had done, were cycling back and forth between 2 bugs and they had just caught the same thing starting again in a pre-release build. After that it just kinda went into the toolbox to look at why code got a certain way instead of assuming the dev wasn't paying attention (or was in fact dim). If you know what someone is trying to do, you can find a solution that solves both problems (without necessarily using either solution).
  - bJGVygG7MQVF8c 6y ago
    100%. Apparently relatively few have experienced the power of `git bisect run`. More than once I've had to explain that no, this isn't just some idiosyncratic aesthetic preference, there's a reason your version control tooling is designed the way it is.
    - enchiridion 6y ago
      I'm afraid I might be one of those people. Care to share? Always looking to level up!
      - renewiltord 6y ago
        If you have a branch which always builds and tests green, you can add a new test, choose a red commit and a green commit and run `git bisect` in a loop to automatically get to the commit that caused the behaviour in that test to regress.
        renox 6y ago
        Did just that last week.. But for some reason, each time I share the result of a git bisect some thinks that I'm a wizard and instead of learning how to do it themselves they ask me later.. Thanks but its git bisect the magic tool not me (writing the shell script did take me some times though).
      - nominatronic 6y ago
        Say someone finds a bug in your software. They're running release 4.1.2. They'd just upgraded from 2.6.4, which is three years old, where what they're doing used to work. You put together a test case and sure enough, it fails on 4.1.2 but passes on 2.6.4. But when did it get broken, and how? The software is complex and you can't see an obvious problem. And looking at the history, there's 4000 commits between those two tagged releases. It would take forever to test them all. You can do something smarter, though. You pick a point somewhere in the middle. Maybe it's around version 3.2.0. You test that version, and it passes. So - assuming the bug only got introduced once - the problematic commit lies somewhere between 3.2.0 and 4.1.2. You pick a version between those, and repeat the process. Rather than testing 4000 different versions, you only have to test about log2(4000) = ~12 versions of the code. The git bisect command is designed to help you with this. If you run the following commands: $ git bisect start $ git checkout v3.2.0 $ <run test, which passes> $ git bisect good $ git checkout v4.1.2 $ <run test, which fails> $ git bisect bad ...then git bisect will take over, choose the commit half way between those, check it out for you and prompt you to run your tests and report the result with 'git bisect good' or 'git bisect bad'. Then depending on the result, it will choose the next commit to test, and repeat the process until it can tell you exactly which commit introduced the bug. But maybe your test takes a while to run. Even with fewer intermediate versions to test, you're going to spend all day running tests, waiting for the results and telling git bisect what to do next. So you automate your test into a little script. If the test passes, it exits with a result of zero (success). If it fails, it returns non-zero. And then you run: $ git bisect run ./my-test-script and go do something else with your day. When you come back, it will have automatically found the commit that introduced the error. Magic! But there's a cost. For this to work, you need discipline from day one. You can't have commits in the history that say "WIP, changed some stuff, not finished yet" and others that fix things up later in the branch. You need to make sure each commit is a fully self-contained change that leaves the code in a working, testable state. If you have a small number of individual commits at which the code won't build cleanly, or which break testing for whatever reason, you can work around them with 'git bisect skip' - and you can implement this in your test script with a special return code. But if this happens too much, the whole approach becomes unmanageable.
  - goda90 6y ago
    My company really pushes finding the cause of bugs since we maintain older versions of our enterprise software and might need to push back patches. Multiple times I've been blamed for bugs just because someone only looked at the first piece of commit history where maybe I moved a big chunk of code into a function or something, when really the bug was introduced 10 revisions back. I'm tempted to take a long vacation to write a code blaming AI.
    - hinkley 6y ago
      And that's why I have commits that are named things like "reformatting code" so that it's clear that I didn't write it.
- Aeolun 6y ago
  I hope that at some point someone would have had the same idea. You always think this is going to be the last fix, so rewriting and enumerating the whole thing seems like a wasted effort, until you do it once too often and it becomes clear you need to rethink your approach.

JoeAltmaier 6y ago

As I recall (and it was a long time ago) the history gave some insight into the complexity. But nobody had exhaustively enumerated all the cases. I remember the chart had more conditions that had ever been addressed.

hinkley 6y ago
You'd be surprised how few people look through commit history while bug fixing. There's a steady stream of people who don't understand why 'breaking' the commit history is a problem, and assume you have some sort of untreated OCD if you bother to even care.
- potta_coffee 6y ago
  Commit history has saved my ass more times than I can count. Especially useful on a codebase that has churned through a lot of developers that you've never met.
  - hinkley 6y ago
    Yeah, including other people's bugs. Worked a few places where people would just give up on bugs well before I did, and less than half of that was perseverance. The first time I recall doing this was when a QA person came to me to complain that in the last handful of releases we had done, were cycling back and forth between 2 bugs and they had just caught the same thing starting again in a pre-release build. After that it just kinda went into the toolbox to look at why code got a certain way instead of assuming the dev wasn't paying attention (or was in fact dim). If you know what someone is trying to do, you can find a solution that solves both problems (without necessarily using either solution).
- bJGVygG7MQVF8c 6y ago
  100%. Apparently relatively few have experienced the power of `git bisect run`. More than once I've had to explain that no, this isn't just some idiosyncratic aesthetic preference, there's a reason your version control tooling is designed the way it is.
  - enchiridion 6y ago
    I'm afraid I might be one of those people. Care to share? Always looking to level up!
    - renewiltord 6y ago
      If you have a branch which always builds and tests green, you can add a new test, choose a red commit and a green commit and run `git bisect` in a loop to automatically get to the commit that caused the behaviour in that test to regress.
      - renox 6y ago
        Did just that last week.. But for some reason, each time I share the result of a git bisect some thinks that I'm a wizard and instead of learning how to do it themselves they ask me later.. Thanks but its git bisect the magic tool not me (writing the shell script did take me some times though).
    - nominatronic 6y ago
      Say someone finds a bug in your software. They're running release 4.1.2. They'd just upgraded from 2.6.4, which is three years old, where what they're doing used to work. You put together a test case and sure enough, it fails on 4.1.2 but passes on 2.6.4. But when did it get broken, and how? The software is complex and you can't see an obvious problem. And looking at the history, there's 4000 commits between those two tagged releases. It would take forever to test them all. You can do something smarter, though. You pick a point somewhere in the middle. Maybe it's around version 3.2.0. You test that version, and it passes. So - assuming the bug only got introduced once - the problematic commit lies somewhere between 3.2.0 and 4.1.2. You pick a version between those, and repeat the process. Rather than testing 4000 different versions, you only have to test about log2(4000) = ~12 versions of the code. The git bisect command is designed to help you with this. If you run the following commands: $ git bisect start $ git checkout v3.2.0 $ <run test, which passes> $ git bisect good $ git checkout v4.1.2 $ <run test, which fails> $ git bisect bad ...then git bisect will take over, choose the commit half way between those, check it out for you and prompt you to run your tests and report the result with 'git bisect good' or 'git bisect bad'. Then depending on the result, it will choose the next commit to test, and repeat the process until it can tell you exactly which commit introduced the bug. But maybe your test takes a while to run. Even with fewer intermediate versions to test, you're going to spend all day running tests, waiting for the results and telling git bisect what to do next. So you automate your test into a little script. If the test passes, it exits with a result of zero (success). If it fails, it returns non-zero. And then you run: $ git bisect run ./my-test-script and go do something else with your day. When you come back, it will have automatically found the commit that introduced the error. Magic! But there's a cost. For this to work, you need discipline from day one. You can't have commits in the history that say "WIP, changed some stuff, not finished yet" and others that fix things up later in the branch. You need to make sure each commit is a fully self-contained change that leaves the code in a working, testable state. If you have a small number of individual commits at which the code won't build cleanly, or which break testing for whatever reason, you can work around them with 'git bisect skip' - and you can implement this in your test script with a special return code. But if this happens too much, the whole approach becomes unmanageable.
- goda90 6y ago
  My company really pushes finding the cause of bugs since we maintain older versions of our enterprise software and might need to push back patches. Multiple times I've been blamed for bugs just because someone only looked at the first piece of commit history where maybe I moved a big chunk of code into a function or something, when really the bug was introduced 10 revisions back. I'm tempted to take a long vacation to write a code blaming AI.
  - hinkley 6y ago
    And that's why I have commits that are named things like "reformatting code" so that it's clear that I didn't write it.
Aeolun 6y ago
I hope that at some point someone would have had the same idea. You always think this is going to be the last fix, so rewriting and enumerating the whole thing seems like a wasted effort, until you do it once too often and it becomes clear you need to rethink your approach.