3 ms·

> The article makes the point that people do not build fences for no reason. It costs time, effort and resources, not to mention it's a lot of work and people a

> The article makes the point that people do not build fences for no reason. It costs time, effort and resources, not to mention it's a lot of work and people are lazy. There's always a reason for the fence. Since this is HN, I think a lot of us have experience with software. If you do, then I find it incredible that you have never discovered some complicated code that serves no real purpose, or at least no good one, and was presumably written to amuse the author more than anything else.

deltarholamda 5y ago
>If you do, then I find it incredible that you have never discovered some complicated code that serves no real purpose Hell, I've written some of that. Very complicated, usually awful code, but it did at one point have a purpose. If somebody wrote something complicated, just for amusement, then that is its purpose. That's a fence that can be rebuilt or thrown away, but you'd better be sure that nothing else references it or otherwise depends on it doing its quirky baroque thing.
iainmerrick 5y ago
But the whole point of Chesterton's Fence is that you don't immediately assume it has no purpose, you put a bit of effort into double checking. If you checked and you're confident it's useless and you can explain why to a reviewer, then sure, remove it. Edit to add: thinking about it, I don't think I've ever found code in a legacy codebase that had literally no purpose. The closest might be code that was once used but now isn't referenced anywhere.
- Thiez 5y ago
  I see code without purpose all the time. I have some colleagues who seem to believe that they should assign `null` to class fields when disposing an object. And no, the object will not be recycled, and never was.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
chucksmash 5y ago
> or at least no good one Understanding whether the purpose was good implies understanding the purpose. Even with very bad code you can at least see what the author was going for. Most code I've seen and felt was bad could be described as "Author needed to do X but wasn't aware of Y." I can't remember a time where I had to deal with code where I couldn't figure out what X was.
- emodendroket 5y ago
  It becomes pretty apparent to me, often, that the author wanted to put something on their resume, or wished to spice up a boring task.
  - a4isms 5y ago
    You keep saying this is your lived experience, and a lot of other people are saying that it is too rare to be worth making a presumption without putting in the work to go look. What I’ll say to you now is that if you are actually looking for the reasons, and all you can find are people making your life hard for the glorification of their ego, you have a much bigger problem than whether it’s worth presuming that there is no reason for code you want to remove: You are located in a local pessimum. Consider working on a different code base. Ask yourself what is going on that you keep running into all this code written by people you disrespect so much.
    - emodendroket 5y ago
      It happens to me infrequently now and I work with a team I really respect. But it took me the better part of a decade to land there.
      - a4isms 5y ago
        Our experiences and outlook may differ, but I am very gratified to hear that you have found your way to a better place.
a4isms 5y ago
Joel Spolsky, just about 22 years ago: Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Yes, it may be the case that we no longer support Internet Explorer, and none of our customers even know that Windows 95 ever existed, much less run it. And our users look at a floopy disk and exclaim "Cool, a 3D-printed save icon!" So yes, lots of code serves "no good purpose" today, even if it was a good purpose when it was written. HARD AGREE. Presumably written to amuse the author? Hard disagree from my n=1 experience, even if that experience with commercial software development dates back to the early 1980s. I think those cases are outliers that exist, but shouldn't drive our decision-making. The key word is "presumably." Presuming that code we find doesn't seem to serve a purpose was written for the self-gratification of the author is, in my experience, a very bad way to manage risk. I'm prepared to assume that code which doesn't seem to serve a purpose may no longer serve a purpose, but while it may never have served a purpose, I'll try my best to find out what that purpose was before throwing it away.
- emodendroket 5y ago
  I could maybe buy that if the code was very old. When it’s a couple months old I find it hard to swallow.
  - 5y ago
mark-r 5y ago
I like Joel Spolsky's take on software rewrites. He never mentions Chesterton but he's thinking along the same lines - old code is a collection of fixes to problems that real people had. You throw it out at your peril. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

deltarholamda 5y ago

>If you do, then I find it incredible that you have never discovered some complicated code that serves no real purpose Hell, I've written some of that. Very complicated, usually awful code, but it did at one point have a purpose. If somebody wrote something complicated, just for amusement, then that is its purpose. That's a fence that can be rebuilt or thrown away, but you'd better be sure that nothing else references it or otherwise depends on it doing its quirky baroque thing.

iainmerrick 5y ago

But the whole point of Chesterton's Fence is that you don't immediately assume it has no purpose, you put a bit of effort into double checking. If you checked and you're confident it's useless and you can explain why to a reviewer, then sure, remove it. Edit to add: thinking about it, I don't think I've ever found code in a legacy codebase that had literally no purpose. The closest might be code that was once used but now isn't referenced anywhere.

Thiez 5y ago
I see code without purpose all the time. I have some colleagues who seem to believe that they should assign `null` to class fields when disposing an object. And no, the object will not be recycled, and never was.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]

chucksmash 5y ago

> or at least no good one Understanding whether the purpose was good implies understanding the purpose. Even with very bad code you can at least see what the author was going for. Most code I've seen and felt was bad could be described as "Author needed to do X but wasn't aware of Y." I can't remember a time where I had to deal with code where I couldn't figure out what X was.

emodendroket 5y ago
It becomes pretty apparent to me, often, that the author wanted to put something on their resume, or wished to spice up a boring task.
- a4isms 5y ago
  You keep saying this is your lived experience, and a lot of other people are saying that it is too rare to be worth making a presumption without putting in the work to go look. What I’ll say to you now is that if you are actually looking for the reasons, and all you can find are people making your life hard for the glorification of their ego, you have a much bigger problem than whether it’s worth presuming that there is no reason for code you want to remove: You are located in a local pessimum. Consider working on a different code base. Ask yourself what is going on that you keep running into all this code written by people you disrespect so much.
  - emodendroket 5y ago
    It happens to me infrequently now and I work with a team I really respect. But it took me the better part of a decade to land there.
    - a4isms 5y ago
      Our experiences and outlook may differ, but I am very gratified to hear that you have found your way to a better place.

a4isms 5y ago

Joel Spolsky, just about 22 years ago: Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters. When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Yes, it may be the case that we no longer support Internet Explorer, and none of our customers even know that Windows 95 ever existed, much less run it. And our users look at a floopy disk and exclaim "Cool, a 3D-printed save icon!" So yes, lots of code serves "no good purpose" today, even if it was a good purpose when it was written. HARD AGREE. Presumably written to amuse the author? Hard disagree from my n=1 experience, even if that experience with commercial software development dates back to the early 1980s. I think those cases are outliers that exist, but shouldn't drive our decision-making. The key word is "presumably." Presuming that code we find doesn't seem to serve a purpose was written for the self-gratification of the author is, in my experience, a very bad way to manage risk. I'm prepared to assume that code which doesn't seem to serve a purpose may no longer serve a purpose, but while it may never have served a purpose, I'll try my best to find out what that purpose was before throwing it away.

emodendroket 5y ago
I could maybe buy that if the code was very old. When it’s a couple months old I find it hard to swallow.
- 5y ago

mark-r 5y ago

I like Joel Spolsky's take on software rewrites. He never mentions Chesterton but he's thinking along the same lines - old code is a collection of fixes to problems that real people had. You throw it out at your peril. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...