4 ms·

I work in a lot of old systems and this is something I have to remind myself of constantly--the people that were working on these systems before me were not nec

by a2tech 5y ago

I work in a lot of old systems and this is something I have to remind myself of constantly--the people that were working on these systems before me were not necessarily dumber than me. If they made these choices, they may have had good reasons for it that are not immediately clear to me, but if I change it may have far flung consequences that I am just not aware of.

Olreich 5y ago
If a change has far flung consequences that aren’t obvious, the code is of poor quality. If the reasons for the decisions are non-obvious, the code is of poor quality. I’ve been bitten y assuming that people thought things through the first time too many times. If it’s not in the code base or documentation, I’m assuming that it was done for expedience. Not because they were dumb, but just because that part of the code base wasn’t important when it was written.
- fvold 5y ago
  Yep, that's what I usually call "four weeks worth of code done in three weeks", and it's the cause of every rewrite I've been a part of so far.
- elygre 5y ago
  > If it’s not in the code base or documentation, I’m assuming that it was done for expedience. That sounds exactly like the kind of judgement the article talks about.
  - tsibelman 5y ago
    Trying to understand everything passively prevent you from actually understanding things, trying to change something will teach you about underlying issues or it will show there no issues.
- kqr 5y ago
  Zoom out a little. Code can work perfectly fine technically yet have far-flung consequences in terms of business cases, human workflows, etc, etc. So it's not as easy as saying "there's always a good reason" or "there's never a good reason". Make a fair effort at uncovering the reason and then it's a judgment call with insufficient data.
  - crehn 5y ago
    Why shouldn't tests catch those far-flung consequences?
    - kqr 5y ago
      We are talking about how human user behaviour changes on a time scale of weeks or months. How would you test that?
  - a2tech 5y ago
    Exactly. Code can pass 100% of tests--but the tests only cover what the test writer knows about. Code, especially old code, can encapsulate TONS of weird human and business specific behavior that you don't know about or doesn't seem sensible at a quick glance. Don't be so quick to dismiss old code--people rarely set out to build something thats shitty and code, especially code that seems completely asinine, is rarely just in there for the lulz.
deleted 5y ago
[deleted]
bradknowles 5y ago
Sounds like Chesterton’s Fence.
- MPSimmons 5y ago
  For anyone, like me, who was unfamiliar with the term: https://fs.blog/chestertons-fence/ https://fs.blog/chestertons-fence/
- mLuby 5y ago
  Chesterton's Fence is indeed linked in this single-page article.
- tomrod 5y ago
  Chesterton's Fence sounds like it was retooled by Jordan Peterson in his definition of truth (broadly: anything evolutionarily useful, Making Sense podcast w/ Sam Harris). Peterson takes it to weird places, IMO, and Chesteron's Fence works better. "Don't remove a fence until you know why it was put there."
  - ajuc 5y ago
    It was a rhetorical device to support conservatism from the beginning. Chesterton was using it to defend Catholicism, but it works just as well for racial segregation, slavery, voting rights restrictions, any status quo.
    - tomrod 5y ago
      That makes a lot of sense. Thanks. It definitely had a "fear the future" vibe in the wikipedia article for it.
VWWHFSfQ 5y ago
I think Spoelsky wrote about this when deciding whether or not to rewrite software.
- dataviz1000 5y ago
  Things You Should Never Do Part 1 [0] [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - crdrost 5y ago
    For the counterpoint from the late great Joe Armstrong, > Rewrite from scratch with zero external dependencies - always the fastest way (or at least the most fun way) - it increases understanding. [1] I don't have a permanent viewpoint on this, I kind of bounce back and forth. I definitely think that whole rewrites are important for getting the module boundaries right, and I think it's important to have seen a problem from a bunch of different perspectives, ideally some of them really bad and borderline outrageous, before you commit to one solution. (“This problem is NP-complete, you just want to brute force it?!” -- yeah it turned out that in practice n was no greater than 9 and you could in fact easily hardcode an upper limit and try all possibilities to find the best one. But even if you don't get lucky, the fact that ridiculous ideas came to mind suggests that all the good ideas were on the table at least once.) Right now I am more inclined to enjoy rewrites because I am working on a project which itself was a rewrite, and I would like to rewrite it back to something more like what it used to be, hah. If I do get my way you can bet I will turn coat, “we can't rewrite this now, don't you know how expensive rewriting is?!” [1] https://twitter.com/joeerl/status/837781189385674753?t=RRItSVWbCvZcUXsKncZMkw&s=19 https://twitter.com/joeerl/status/837781189385674753?t=RRItS...

by a2tech 5y ago

Olreich 5y ago

If a change has far flung consequences that aren’t obvious, the code is of poor quality. If the reasons for the decisions are non-obvious, the code is of poor quality. I’ve been bitten y assuming that people thought things through the first time too many times. If it’s not in the code base or documentation, I’m assuming that it was done for expedience. Not because they were dumb, but just because that part of the code base wasn’t important when it was written.

fvold 5y ago
Yep, that's what I usually call "four weeks worth of code done in three weeks", and it's the cause of every rewrite I've been a part of so far.
elygre 5y ago
> If it’s not in the code base or documentation, I’m assuming that it was done for expedience. That sounds exactly like the kind of judgement the article talks about.
- tsibelman 5y ago
  Trying to understand everything passively prevent you from actually understanding things, trying to change something will teach you about underlying issues or it will show there no issues.
kqr 5y ago
Zoom out a little. Code can work perfectly fine technically yet have far-flung consequences in terms of business cases, human workflows, etc, etc. So it's not as easy as saying "there's always a good reason" or "there's never a good reason". Make a fair effort at uncovering the reason and then it's a judgment call with insufficient data.
- crehn 5y ago
  Why shouldn't tests catch those far-flung consequences?
  - kqr 5y ago
    We are talking about how human user behaviour changes on a time scale of weeks or months. How would you test that?
- a2tech 5y ago
  Exactly. Code can pass 100% of tests--but the tests only cover what the test writer knows about. Code, especially old code, can encapsulate TONS of weird human and business specific behavior that you don't know about or doesn't seem sensible at a quick glance. Don't be so quick to dismiss old code--people rarely set out to build something thats shitty and code, especially code that seems completely asinine, is rarely just in there for the lulz.

deleted 5y ago

[deleted]

bradknowles 5y ago

Sounds like Chesterton’s Fence.

MPSimmons 5y ago
For anyone, like me, who was unfamiliar with the term: https://fs.blog/chestertons-fence/ https://fs.blog/chestertons-fence/
mLuby 5y ago
Chesterton's Fence is indeed linked in this single-page article.
tomrod 5y ago
Chesterton's Fence sounds like it was retooled by Jordan Peterson in his definition of truth (broadly: anything evolutionarily useful, Making Sense podcast w/ Sam Harris). Peterson takes it to weird places, IMO, and Chesteron's Fence works better. "Don't remove a fence until you know why it was put there."
- ajuc 5y ago
  It was a rhetorical device to support conservatism from the beginning. Chesterton was using it to defend Catholicism, but it works just as well for racial segregation, slavery, voting rights restrictions, any status quo.
  - tomrod 5y ago
    That makes a lot of sense. Thanks. It definitely had a "fear the future" vibe in the wikipedia article for it.

VWWHFSfQ 5y ago

I think Spoelsky wrote about this when deciding whether or not to rewrite software.

dataviz1000 5y ago
Things You Should Never Do Part 1 [0] [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- crdrost 5y ago
  For the counterpoint from the late great Joe Armstrong, > Rewrite from scratch with zero external dependencies - always the fastest way (or at least the most fun way) - it increases understanding. [1] I don't have a permanent viewpoint on this, I kind of bounce back and forth. I definitely think that whole rewrites are important for getting the module boundaries right, and I think it's important to have seen a problem from a bunch of different perspectives, ideally some of them really bad and borderline outrageous, before you commit to one solution. (“This problem is NP-complete, you just want to brute force it?!” -- yeah it turned out that in practice n was no greater than 9 and you could in fact easily hardcode an upper limit and try all possibilities to find the best one. But even if you don't get lucky, the fact that ridiculous ideas came to mind suggests that all the good ideas were on the table at least once.) Right now I am more inclined to enjoy rewrites because I am working on a project which itself was a rewrite, and I would like to rewrite it back to something more like what it used to be, hah. If I do get my way you can bet I will turn coat, “we can't rewrite this now, don't you know how expensive rewriting is?!” [1] https://twitter.com/joeerl/status/837781189385674753?t=RRItSVWbCvZcUXsKncZMkw&s=19 https://twitter.com/joeerl/status/837781189385674753?t=RRItS...