5 ms·

That is a fantastic tidbit, TIL. This is pretty much what I had in mind to refute the assumption the earlier parent made about rewrites being desired so code do

That is a fantastic tidbit, TIL. This is pretty much what I had in mind to refute the assumption the earlier parent made about rewrites being desired so code doesn't have to be grokked. IME, the tech debt we complained about was in situations where we knew what we had to do to write a new feature, and why it wouldn't work because of the decisions made previously, and the monumental amount of work involved in putting just one more bandaid on that system, instead of just fixing the dang data model.

ben509 8y ago
That makes me wonder: if I fix something, if I set up Chesterton's fence, how can I make it a bit more obvious why I'm putting that fence there for the benefit of future us?
- MaxBarraclough 8y ago
  The usual code-comments/self-documenting code/git commit descriptions, no? If a long-form explanation is justified, wikis are cheap. I see no excuse for leaving the reader to guess at what on Earth you were thinking. Implementing a wacky solution is sometimes a necessary evil. Incomprehensibility isn't.
- gknoy 8y ago
  At the risk of sounding snarky, I feel like a block of code comments explaining the naiive approach that was rejected, as well as the particular edge cases that this is handling which the simpler generalized case doesn't handle, would help a lot for that. I realize that as developers we often glaze over the comments (my editor even shows them as low contrast grey), but docstrings and code comments can be tremendously valuable when trying to understand why something needs to do things a particular way.
- hinkley 8y ago
  I am downright militant about people not relocating code and breaking the commit history. When I see WTF code, I want to know what story it was associated with so I know why the fences were erected. Sometimes they are right and I need a complex solution. Sometimes they were accomplishing something the hard way and there was an easier spot to achieve the goal. Basically I am fixing two bugs. The old one again, and the new one.

ben509 8y ago

That makes me wonder: if I fix something, if I set up Chesterton's fence, how can I make it a bit more obvious why I'm putting that fence there for the benefit of future us?

MaxBarraclough 8y ago
The usual code-comments/self-documenting code/git commit descriptions, no? If a long-form explanation is justified, wikis are cheap. I see no excuse for leaving the reader to guess at what on Earth you were thinking. Implementing a wacky solution is sometimes a necessary evil. Incomprehensibility isn't.
gknoy 8y ago
At the risk of sounding snarky, I feel like a block of code comments explaining the naiive approach that was rejected, as well as the particular edge cases that this is handling which the simpler generalized case doesn't handle, would help a lot for that. I realize that as developers we often glaze over the comments (my editor even shows them as low contrast grey), but docstrings and code comments can be tremendously valuable when trying to understand why something needs to do things a particular way.
hinkley 8y ago
I am downright militant about people not relocating code and breaking the commit history. When I see WTF code, I want to know what story it was associated with so I know why the fences were erected. Sometimes they are right and I need a complex solution. Sometimes they were accomplishing something the hard way and there was an easier spot to achieve the goal. Basically I am fixing two bugs. The old one again, and the new one.