5 ms·

It was me ... several times I have found a bug or code smell and then been surprised that the I was the original author. For the last fifteen to twenty years,

by smoyer 5y ago

It was me ... several times I have found a bug or code smell and then been surprised that the I was the original author. For the last fifteen to twenty years, I've generally found looking at code I wrote six months ago equally distasteful. So now my default behavior is to assume the code met the business function at the time, acknowledge that I'm continuously improving in my craft and finally, gained a joy in spending part of my time doing maintenance programming.

berkes 5y ago
I'm a strong believer in continuous refactoring. Improve existing code when you touch it. Defer architectural choices untill the moment you have enough info. And leave cleaning up to the moment that it starts becoming messy, not before. That implies, code never is perfect. Not even good. But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand.
- bumby 5y ago
  >But always just about 'good enough' to solve the issue at hand. I think this is context dependent. I generally agree with this statement on relatively low-risk projects. The problem with "good enough" is that it often becomes a rationale for our cognitive biases to take the easier route. I don't want someone doing that on, say, safety-critical code. Maintaining high standards is a way of buffering against those cognitive biases.
  - berkes 5y ago
    > context dependent Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
    - bumby 5y ago
      I suppose, but by that same token standards would be the definition of pre-defined "good enough". In my experience, the nebulous nature of the term is usually a means of rationalizing a sub-standard effort. The benefit of defining that threshold upfront is that it's hopefully more objective, before you let cognitive biases influence your decision making. It really comes down to understanding why the goalposts have moved. Is it because you have more information to reduce the uncertainty about the risks that standards are meant to be mitigate? If so, great! If not, it's a red flag you may be responding to something else that increases risk, like schedule or cost pressure.
      - shkkmo 5y ago
        The point is that there is no one predefined "good enough", but rather the level of quality that code needs to reach is context dependent. That is why you end up constantly refactoring a little each time you touch the code as that context has usually shifted.
        bumby 5y ago
        I disagree. There are lots of examples of standards that define what is "good enough." For example, NASA has different standards depending on risk categorization and the predefined threshold of quality gradually gets higher as the use gets riskier. A business application is held to a much lower level of quality than software for a robotic mission which is lower than a human rated development effort.
        shkkmo 5y ago
        I can't tell what you are arguing about? We are laying out an approach to software development, refactoring, and a model for how to view old code that you some acroas that seems bad. You seem to be stuck on the term "good enough" and arguing semantics that don't make sense. Yes, sometimes there are standards. that you need to meet. Sometimes just meeting the offical standard is not "good enough", and you need to do more. "Good enough" is inherently contextual, and you seem to agree with this, but seem still be arguing against using that term?
- hutzlibu 5y ago
  I reached the same conclusion. I just would add, that the urge to refactor things whenever possible, definitely introduced bugs for me, because also refactoring has to be done with consideration and some things were weird for a reason, you do not see at first glance. And refactoring can also hurt you, or another person just used to that code in its old shape. And then missunderstanding things.
  - berkes 5y ago
    > definitely introduced bugs for me I'm an avid TDD developer. Red-green*refactor*. The latter, often overlooked, is IMO by far the most important part of TDD. But the refactor is only possible because of the tests you wrote, asserted, and tested (testing the tests) in the red-green phase. It gets hairy when a refactor needs to also refactor the tests - often a sign that the tests were lacking in the first place (and the more reason to refactor them). In which case I try to refactor them not in lock-step but decoupled: first refactor the tests without touching the SUT. Then refactor SUT (and then, most likely, another round of this) There is no fool-proof way. There will be bugs. There will be regressions. But that is a artifact of "change", not of refactoring. I'm also a believer in "never fix something that ain't broken". Which, unfortunately, only works for software that is not ever upgraded, has no dependencies, runs on hard- and software stacks that never change and has no changing business-needs ever. I.e.: non-existing software.
    - hutzlibu 5y ago
      One day I probably shift into TDD as well, as .. yes, I am not big on systematic testing. And that often hurt a lot.
      - berkes 5y ago
        TBH: TDD is not a silver bullet. And applying it religiously where it did not fit, has hurt me just as much as not applying it, where I should have.
- Orou 5y ago
  > always just about 'good enough' to solve the issue at hand I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.
  - berkes 5y ago
    > this approach really bite teams Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover. "Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc. Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)
wildzzz 5y ago
There's a bunch of little scripts I've had to write for my workflow. Time is short so I've taken parts and pieces from experiments, treated them as black boxes, and wrote interfaces to make them handle way more than I ever anticipated. It usually looks bad and has little useful documentation for the heavy math inside but it works and will work for years. I try to spend time on making the interface clear and friendly for anyone else that uses it after me but the internals are a nest of wires and obtuse mechanisms that I can barely remember how they work. We had an excel spreadsheet that was used for at least a decade to process some measurements. There were a lot of magic numbers shoved in the equations to handle some issues with the equipment along with math that I'm surprised Excel can handle. The results would be correct but it was a total black box but the steps to get to them were nearly incomprehensible. A coworker decided to spend some time upgrading it to Matlab to allow for some better interfacing with new test equipment we were buying. She thought it would take a week, it took months. Talking to the original author was useless as he couldn't remember how he built any of it. Finally she got it working with both the old and new test equipment and now has properly documented everything so it explains the use of any magic numbers. I did not envy that job at all.
hinkley 5y ago
I was honestly surprised the author's answer was "my friend Torben" and not, "oh, it was me". Part of the reason I like to write as little code as possible is that anything over a year old has some antipattern that I've come to loathe. I can't hate code that didn't get written in the first place. Or at least, it's a lot harder to do so.

by smoyer 5y ago

berkes 5y ago

I'm a strong believer in continuous refactoring. Improve existing code when you touch it. Defer architectural choices untill the moment you have enough info. And leave cleaning up to the moment that it starts becoming messy, not before. That implies, code never is perfect. Not even good. But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand.

bumby 5y ago
>But always just about 'good enough' to solve the issue at hand. I think this is context dependent. I generally agree with this statement on relatively low-risk projects. The problem with "good enough" is that it often becomes a rationale for our cognitive biases to take the easier route. I don't want someone doing that on, say, safety-critical code. Maintaining high standards is a way of buffering against those cognitive biases.
- berkes 5y ago
  > context dependent Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
  - bumby 5y ago
    I suppose, but by that same token standards would be the definition of pre-defined "good enough". In my experience, the nebulous nature of the term is usually a means of rationalizing a sub-standard effort. The benefit of defining that threshold upfront is that it's hopefully more objective, before you let cognitive biases influence your decision making. It really comes down to understanding why the goalposts have moved. Is it because you have more information to reduce the uncertainty about the risks that standards are meant to be mitigate? If so, great! If not, it's a red flag you may be responding to something else that increases risk, like schedule or cost pressure.
    - shkkmo 5y ago
      The point is that there is no one predefined "good enough", but rather the level of quality that code needs to reach is context dependent. That is why you end up constantly refactoring a little each time you touch the code as that context has usually shifted.
      - bumby 5y ago
        I disagree. There are lots of examples of standards that define what is "good enough." For example, NASA has different standards depending on risk categorization and the predefined threshold of quality gradually gets higher as the use gets riskier. A business application is held to a much lower level of quality than software for a robotic mission which is lower than a human rated development effort.
        shkkmo 5y ago
        I can't tell what you are arguing about? We are laying out an approach to software development, refactoring, and a model for how to view old code that you some acroas that seems bad. You seem to be stuck on the term "good enough" and arguing semantics that don't make sense. Yes, sometimes there are standards. that you need to meet. Sometimes just meeting the offical standard is not "good enough", and you need to do more. "Good enough" is inherently contextual, and you seem to agree with this, but seem still be arguing against using that term?
hutzlibu 5y ago
I reached the same conclusion. I just would add, that the urge to refactor things whenever possible, definitely introduced bugs for me, because also refactoring has to be done with consideration and some things were weird for a reason, you do not see at first glance. And refactoring can also hurt you, or another person just used to that code in its old shape. And then missunderstanding things.
- berkes 5y ago
  > definitely introduced bugs for me I'm an avid TDD developer. Red-green*refactor*. The latter, often overlooked, is IMO by far the most important part of TDD. But the refactor is only possible because of the tests you wrote, asserted, and tested (testing the tests) in the red-green phase. It gets hairy when a refactor needs to also refactor the tests - often a sign that the tests were lacking in the first place (and the more reason to refactor them). In which case I try to refactor them not in lock-step but decoupled: first refactor the tests without touching the SUT. Then refactor SUT (and then, most likely, another round of this) There is no fool-proof way. There will be bugs. There will be regressions. But that is a artifact of "change", not of refactoring. I'm also a believer in "never fix something that ain't broken". Which, unfortunately, only works for software that is not ever upgraded, has no dependencies, runs on hard- and software stacks that never change and has no changing business-needs ever. I.e.: non-existing software.
  - hutzlibu 5y ago
    One day I probably shift into TDD as well, as .. yes, I am not big on systematic testing. And that often hurt a lot.
    - berkes 5y ago
      TBH: TDD is not a silver bullet. And applying it religiously where it did not fit, has hurt me just as much as not applying it, where I should have.
Orou 5y ago
> always just about 'good enough' to solve the issue at hand I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.
- berkes 5y ago
  > this approach really bite teams Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover. "Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc. Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)

wildzzz 5y ago

There's a bunch of little scripts I've had to write for my workflow. Time is short so I've taken parts and pieces from experiments, treated them as black boxes, and wrote interfaces to make them handle way more than I ever anticipated. It usually looks bad and has little useful documentation for the heavy math inside but it works and will work for years. I try to spend time on making the interface clear and friendly for anyone else that uses it after me but the internals are a nest of wires and obtuse mechanisms that I can barely remember how they work. We had an excel spreadsheet that was used for at least a decade to process some measurements. There were a lot of magic numbers shoved in the equations to handle some issues with the equipment along with math that I'm surprised Excel can handle. The results would be correct but it was a total black box but the steps to get to them were nearly incomprehensible. A coworker decided to spend some time upgrading it to Matlab to allow for some better interfacing with new test equipment we were buying. She thought it would take a week, it took months. Talking to the original author was useless as he couldn't remember how he built any of it. Finally she got it working with both the old and new test equipment and now has properly documented everything so it explains the use of any magic numbers. I did not envy that job at all.

hinkley 5y ago

I was honestly surprised the author's answer was "my friend Torben" and not, "oh, it was me". Part of the reason I like to write as little code as possible is that anything over a year old has some antipattern that I've come to loathe. I can't hate code that didn't get written in the first place. Or at least, it's a lot harder to do so.