4 ms·

well and good. the issue I have is that when no one can be found that knows anything about why it was put there in the first place. every day I have to climb ov

well and good. the issue I have is that when no one can be found that knows anything about why it was put there in the first place. every day I have to climb over that damn fence to get groceries. at what point do we tear it down to see what happens? in software, I would rather tear it down and find out what it was there for. most developers I've worked with in the past couple decades operate in an atmosphere of constant fear and would never consider doing that. even if the cost of putting it back is zero. better to climb over it every day than risk introducing some unknown inconsistency. maybe we'd be better engineers if we actually learned about the systems we're using.

TopYemen 4y ago
osigurdson 4y ago
If you have good tests, the reason is often much more clear.
friedman23 4y ago
> in software, I would rather tear it down and find out what it was there for. if you don't have regression testing there's a chance you don't find out until something disastrous happens
- 8note 4y ago
  There's a reason it's called a scream test. You take out the fence, then watch closely for the disaster. Likely the fence was unnecessary because most fences are built to accomodate for somebody's personal tastes and aesthetics
celsopitta 4y ago
When you remove something from the software you are improving your understanding of it. I don't see how this example adds to your argument.
- convolvatron 4y ago
  i'm sorry I was unclear. yes - I strongly recommend removing the fence and seeing what happens. climbing over it every day and giving it a glare just leaves you in the dark.
sanderjd 4y ago
The recourse when nobody can be found who knows or remembers why the fence is there, is to figure it out based on first principles. It's fine to do "tear it down and see what happens" as a consciously chosen trade-off for expediency. But in my experience people often act like there's just no way of knowing if you can't find someone to ask, and that's very rarely the case.
- msla 4y ago
  In software, sure, reasoning from first principles is likely to work. With older traditions, it could just as easily lead you to just-so stories and other false explanations, such as the endless number of false etymologies which make all seasoned linguists deeply suspicious of any cute etymology, especially one which could be used to make a point.
  - sanderjd 4y ago
    Sure, I was talking about software. I think lots of other things are attackable from first principles. But sure, some aren't.
- P5fRxh5kUvp2th 4y ago
  So true. "What do you mean add in logging and watch it over several months?!?!?! I'll have to climb the fence for several more months, that's not acceptable!". ok...
II2II 4y ago
> at what point do we tear it down to see what happens? Without knowing the purpose of something, we cannot know the cost of removing it. A few weeks someone commented to me on how they thought that some chain link fencing along a railing should be removed because it was unsightly, until they saw a toddler playing near the railing and realized that the toddler could easily squeeze through if the chain link fencing wasn't there. If they never saw the toddler, they would have thought the fencing pointless. If the people they asked failed to think of the size or behaviour of toddlers, their conclusion would remain unchanged. Yet, had that chain link fencing been removed, the results have been tragic. Because of the nature of my work, I can think of many other circumstances where safety measures have been put into place where only a few people would understand their purpose. In most cases the reason is less obvious than that bit of fencing. Unfortunately, few of them have the element where someone realizes the purpose out of chance before the damage was done. Much the same can be said of software. It may seem like it is fine to pull out a piece of code, test it outside of a production environment, and give it the okay when everything works. Yet it may not be fine. That code may have been inserted to deal with a problem that client X was having to deal with one of their requirements or to deal with a peculiarity of their production environment. Because it is particular to a particular client, the development team may not know of it (e.g. the developer who did the work is long gone) or it may have simply been forgotten. Just because the purpose is unknown in the present doesn't mean that removing it is devoid of consequence. Those consequences may range from impacting their procedures, to financial loss, to safety. At the end of the day, you need to understand why something exists to determine if it is still relevant. It should be removed only once you know that it is no longer relevant.
- notriddle 4y ago
  I hope they added a sign, “keep children away from train,” to the fence.
- midoridensha 4y ago
  This reminds me of the story of Muntz TVs. Mr. Muntz was a self-taught engineer who made a company that produced TVs at significantly lower prices than everyone else, and there's stories of how he'd work with his engineers and just randomly remove parts he didn't think were necessary, to cut costs. Many times, it worked, so the production design adopted these changes. The problem was, while these minimalist-component TVs seemed to work OK in the lab, or in most customers' homes, they didn't work very well in edge cases (like people in locations with poorer signal strength).

TopYemen 4y ago

osigurdson 4y ago

If you have good tests, the reason is often much more clear.

friedman23 4y ago

> in software, I would rather tear it down and find out what it was there for. if you don't have regression testing there's a chance you don't find out until something disastrous happens

8note 4y ago
There's a reason it's called a scream test. You take out the fence, then watch closely for the disaster. Likely the fence was unnecessary because most fences are built to accomodate for somebody's personal tastes and aesthetics

celsopitta 4y ago

When you remove something from the software you are improving your understanding of it. I don't see how this example adds to your argument.

convolvatron 4y ago
i'm sorry I was unclear. yes - I strongly recommend removing the fence and seeing what happens. climbing over it every day and giving it a glare just leaves you in the dark.

sanderjd 4y ago

The recourse when nobody can be found who knows or remembers why the fence is there, is to figure it out based on first principles. It's fine to do "tear it down and see what happens" as a consciously chosen trade-off for expediency. But in my experience people often act like there's just no way of knowing if you can't find someone to ask, and that's very rarely the case.

msla 4y ago
In software, sure, reasoning from first principles is likely to work. With older traditions, it could just as easily lead you to just-so stories and other false explanations, such as the endless number of false etymologies which make all seasoned linguists deeply suspicious of any cute etymology, especially one which could be used to make a point.
- sanderjd 4y ago
  Sure, I was talking about software. I think lots of other things are attackable from first principles. But sure, some aren't.
P5fRxh5kUvp2th 4y ago
So true. "What do you mean add in logging and watch it over several months?!?!?! I'll have to climb the fence for several more months, that's not acceptable!". ok...

II2II 4y ago

> at what point do we tear it down to see what happens? Without knowing the purpose of something, we cannot know the cost of removing it. A few weeks someone commented to me on how they thought that some chain link fencing along a railing should be removed because it was unsightly, until they saw a toddler playing near the railing and realized that the toddler could easily squeeze through if the chain link fencing wasn't there. If they never saw the toddler, they would have thought the fencing pointless. If the people they asked failed to think of the size or behaviour of toddlers, their conclusion would remain unchanged. Yet, had that chain link fencing been removed, the results have been tragic. Because of the nature of my work, I can think of many other circumstances where safety measures have been put into place where only a few people would understand their purpose. In most cases the reason is less obvious than that bit of fencing. Unfortunately, few of them have the element where someone realizes the purpose out of chance before the damage was done. Much the same can be said of software. It may seem like it is fine to pull out a piece of code, test it outside of a production environment, and give it the okay when everything works. Yet it may not be fine. That code may have been inserted to deal with a problem that client X was having to deal with one of their requirements or to deal with a peculiarity of their production environment. Because it is particular to a particular client, the development team may not know of it (e.g. the developer who did the work is long gone) or it may have simply been forgotten. Just because the purpose is unknown in the present doesn't mean that removing it is devoid of consequence. Those consequences may range from impacting their procedures, to financial loss, to safety. At the end of the day, you need to understand why something exists to determine if it is still relevant. It should be removed only once you know that it is no longer relevant.

notriddle 4y ago
I hope they added a sign, “keep children away from train,” to the fence.
midoridensha 4y ago
This reminds me of the story of Muntz TVs. Mr. Muntz was a self-taught engineer who made a company that produced TVs at significantly lower prices than everyone else, and there's stories of how he'd work with his engineers and just randomly remove parts he didn't think were necessary, to cut costs. Many times, it worked, so the production design adopted these changes. The problem was, while these minimalist-component TVs seemed to work OK in the lab, or in most customers' homes, they didn't work very well in edge cases (like people in locations with poorer signal strength).