7 ms·

This philosophy is one of the cornerstones of my engineering practice. IFF you can describe why something is there - without using shortcuts/crutches like 'thei

This philosophy is one of the cornerstones of my engineering practice. IFF you can describe why something is there - without using shortcuts/crutches like 'their dumb' - then we may be able to consider changing it. Otherwise, it's dangerous and risky to fool with it. Too many times did I see something absurd and paint myself into a corner trying to 'fix' it, when there really was a bizarre edge case that this covered. (And in plants, you usually only find these edge cases after enormously expensive production loss events!) And it's a fantastic principle in general, since it's like the technical equivalent of the Principle of Charity. ( http://philosophy.lander.edu/oriental/charity.html http://philosophy.lander.edu/oriental/charity.html )

JoshTriplett 11y ago
While that's entirely true, it's also true that any code covering an obscure corner case ought to document that corner case and why the code is needed. And similarly, any policy or law should be completely clear about what problem it wants to solve. That would make it far easier to maintain.
- run4yourlives2 11y ago
  This is kind of irrelevant though. Sure it should be documented, and sure the fence should have a nice notice of purpose posted right at the gate for everyone to see, but life doesn't work like that.
  - Bartweiss 11y ago
    I'm not sure I'd go as far as irrelevant - rather, I would say that documentation is what you do to keep other people from needing the principle of charity. They're two directions on solving the same problem. As a maintainer you should assume good intentions, but as a creator you should work to clarify your intent.
    - run4yourlives2 11y ago
      Agreed, but irrelevant to this particular conversation, which is about how to handle a "fence" in the road where there is no obvious reason evident.
- Bartweiss 11y ago
  Documentation is essentially the proactive version of the idea for which the principle of charity is the reactive version. Assume that those who came before you had good reasons for their actions, and assume that those after you will be unable to identify any motivation you don't state explicitly. I'd be curious to see a strong legislative version of this - enshrining the spirit of the law in the text, and giving courts explicit rights to strike down laws which no longer fulfill their original intent. Done well, it's the sort of change which could have worked wonders on our legal system's constant failure to adapt to technological change. The Aereo suit, for instance, shouldn't have happened under any kind of intent-based legal system.
  - JoshTriplett 11y ago
    > Assume that those who came before you had good reasons for their actions There's a limit to that assumption, though. I'm always inclined to assume that people had reasons, and that they looked good at the time, but without knowing what those reasons are, there's no way to know if the reasons are as good now as they were then, even if you make the charitable assumption that they were good reasons at the time. I would be a big fan of the idea that legislation had built-in turnover clauses, for instance, that required renewal every N years (for a value of N not much larger than the turnover rate of legislators). Which then means if you want something to persist, you would have to document your rationale for posterity, and convincingly argue that that rationale still applies. > I'd be curious to see a strong legislative version of this - enshrining the spirit of the law in the text, and giving courts explicit rights to strike down laws which no longer fulfill their original intent. I agree completely. Laws should state up front that "the purpose of this law is to ...", and for that matter explicitly state any other relevant considerations or side effects and whether they're considered beneficial, undesired, or simply neutral. That would mean there would have to be at least a pretense of a sensible motive, and that interpretations that don't serve that motive could be thrown out. > The Aereo suit, for instance, shouldn't have happened under any kind of intent-based legal system. It still could have, depending on the intent. The intent of copyright law, for instance, is supposed to be "we want more works produced, but we also want more works to enrich the public domain, so there's a tradeoff". The intent was never about authors and what they want; that's a means to an end. However, that rarely seems to be reflected in deliberations.
swanson 11y ago
This is an awesome comment, thank you for sharing. Do you know of any other resources/materials like this? (Specifically would love to learn more about these kind of principles as related to mechanical engineering or a factory/process setting)
- malingo 11y ago
  An amusing anecdote is the onion in the varnish: http://c2.com/cgi/wiki?OnionInTheVarnish http://c2.com/cgi/wiki?OnionInTheVarnish
- HCIdivision17 11y ago
  Foolishly, I don't really. I made the connection in some other thread on HN, and it's stuck with me. My advice is perhaps terrible: find yourself an old engineer and just do whatever it takes to be their friend and follow 'em like a puppy. It's sorta weird how effective it is to just be around people like that (and I think some PE licenses actually require apprenticeships for that reason). But I do have two formative things: Feynman's lecture on Cargo Cult Science is excellent, with this gem: "The first principle is that you must not fool yourself--and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other scientists. You just have to be honest in a conventional way after that... I'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen." - Feynman [0] I can't tell you how many times this has saved me in the field. Replace the word 'scientist' with '<YOUR DISCIPLINE HERE>' as needed. (And I think moreso for engineers than scientists, since safety absolutely requires this mentality.) And I really like the ideas in The Pragmatic Programmer [1]. More than anything specific, the idea of not being married to any particular concept or solution, but rather to pragmatically chose what is correct then for that circumstance helps a lot. The book is opinionated, but reasonable, and copying that pleasant tone is a fast way to make allies when solving problems in a group. And it's a pretty good book to boot. [0] http://neurotheory.columbia.edu/~ken/cargo_cult.html http://neurotheory.columbia.edu/~ken/cargo_cult.html (and is an HN favorite, to be sure) [1] https://pragprog.com/the-pragmatic-programmer https://pragprog.com/the-pragmatic-programmer (another HN favorite, though not always brought up in terms of engineering)
Bartweiss 11y ago
Chesterton's Fence should be one of the core principles of software development, and it calls to mind the famous "Never rewrite software" article. If you're refactoring, you can use unit tests and proofs of equivalence to demonstrate that your changes don't pose a threat. If you're rewriting a whole codebase, you're likely to wander down the same paths of "wait, the simple way doesn't work" that the person before you took. Even bafflingly small changes like removing always-false tests have been known to break code, which ought to inspire real hesitation any time you see "stupid" code written by a smart person.
- loup-vaillant 11y ago
  > Even bafflingly small changes like removing always-false tests have been known to break code Okay, how is this even possible? Reflection/pre-processing magic?
  - barrkel 11y ago
    Compiler codegen bugs.
    - Gibbon1 11y ago
      I've had a few compiler bugs where, adding an if false or changing the order of an if test 'fixes' things. And the complement changing the code exposes a compiler bug. And also, new improved compiler results in code that's broken. Other issues I run into a fair amount is dealing with hardware/naked interrupts often involves a lot of subtle timing and read/write access issues. Sometimes this happens in code you don't own.
  - brianpan 11y ago
    Another comment in this post: >I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices. https://news.ycombinator.com/item?id=10036050 https://news.ycombinator.com/item?id=10036050 I can also imagine methods with side-effects. The test is always false but a side-effect is necessary.
Too 11y ago
I worked in a similar setting, writing safety critical code. Any time we found code that was so dumb that it couldn't possibly be correct, without documenting why, we still did a blame to see when it was written, if the blame was older than the current source control system we did a blame in the previous one (this could be 10 year old code). Once we found when it was written we looked at any commit messages, if nothing obvious was written there we looked at general code movement around the time of the commit, we looked at any documents changed around the time of the commit, we looked at issue tracker tickets filed and closed around the time of the commit, we looked at test cases written around the time of the commit, test reports that had different results before/after. In essence we did everything in order to understand how the person thought when writing the code. This had always been a code base with very rigorous processes around it so explaining things by "he probably was lazy and let it slip by" was not a valid excuse before all other reasons had been investigated. Obvious "errors" like if(false) is a stupid example of this, why would someone commit if(false)? Is it supposed to be if(true)? Is it for debugging only or is it code that should actually be removed? Maybe it's used for other reasons by a preprocessing-tool that you are not aware of?
- Bartweiss 11y ago
  This is a great story/summary, and it underlines the value of being able to "hear from" the code's original author (either by contacting them, or preferably by referring to high-quality documentation saying "this looks stupid, here's why"). I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices. The stupider the "error", the more suspicion you should assign to its presence in any half-decent code.
wyager 11y ago
The principle of charity sounds extremely questionable; what is the purported benefit of suspending logical thought for the purposes of understanding something that may be wrong? I want to understand the idea logically, so I don't want to substitute in some second-rate folk understanding while I'm considering it.
- Bartweiss 11y ago
  The principle of charity is basically a way to approach new ideas arising from mindsets different than yours. The 'assumption of truth' step doesn't require us to believe anyone who walks up and says "A ^ ~A". Rather, it says that you shouldn't immediately reject a philosophy because it disagrees with your prior notions. The 'resolve contradictions' similarly doesn't mean that we have to overlook flawed claims. It's a tool to help learn an idea even if you don't get a perfect presentation of it. There may be a valuable concept available even if the person explaining it to you can't properly work through every detail. As an example, most people who could talk to you about evolution can't explain the development of eyes, but that doesn't mean you should assume evolution is bunk when you hear about it. The principle of charity says "there might be a good reason here, whether or not they can provide it". In short, the principle is an attempt to get value out of ideas you're presented with. That might mean you're engaging with a different idea than what you were actually presented with, but it gets you more insight. It's not something you want to use when faced with a concrete form of the document - it's not a reason to pass a bad-but-well-intentioned law.
- 5040 11y ago
  The principle of charity asks you to grapple with the best possible version of an argument. If the one making the argument makes an obvious mistake, correct it and take on the corrected argument rather than the flawed one. Nowhere is logical thought suspended. The goal should be truth, so why fixate on small mistakes instead of fixing them and engaging with a sounder argument?
- HCIdivision17 11y ago
  It's not questionable, just good practice. And my experience tells me it's a Best Practice. `Bartweiss gives a good overview of it, but I'll share some advice I got from an engineering greybeard (which I most definitely am not). He had a great story to go with this, but the TLDR is that the PoC is the safe choice when applied to engineering: give a true, best-faith effort to prove the opposing view correct. (And best-faith is important: you can not approach it with bias, lest you waste everyone's time.) If you're right, then you'll find an irrefutable flaw in the engineering, and if you're wrong you've learned something new. If it sounds like a lot of effort, it is. But this is also utterly win-win. It's a way of assuring that you've been careful. Avoiding the humiliation of hubris is great if a detail of the implementation was missed at first glance. But you also will inevitably more fully understand the problem when you've failed to implement the opposing view; it also puts you in the excellent position to graciously be on the same side as your opponent and now you can sway your now-ally-in-war in their reasoning. In either way, your goal must be to solve the problem, and not merely "win" political points. Of course, there's crackpot theories and stupid ideas and foolish plans which should be dismissed with prejudice. But hopefully you're working in a professional environment where your coworkers really are trying their best to succeed. And even then, a serious engineer will still give the stupid ideas at least some (small) time of day, as you must have a reason for all decisions, even dismissals; as you become experienced, you'll be able to properly dismiss these faster and more precisely, but you'll still need to go through the process. That process is what separates the people who loudly proclaim they are smart and right from those who would testify in court they are right. (Incidentally, this is part of the reason why I get immensely frustrated with "idea people", as it takes much more work to flesh out their half-assed ideas into full-assed ideas. Non-engineers don't get that there's a huge amount of effort to constantly take everything and everyone seriously.)
Nacraile 11y ago
I'm going to dispute the "iff". Chesterton's fence is a useful idea to keep in mind, but it is flawed in that it is excessively conservative. It demands that you prove a negative, which is not reasonable in general. (How do you prove that that apparently useless doohicky isn't staving off Cthulu's wrath?). It's important to try to understand why something exists, but it is also important to understand that the reason often is that it was either unintentional or silly, but you won't be able to prove it because it isn't documented and the person responsible is gone/unknown.
- taejo 11y ago
  Chesterton's fence doesn't require you to prove that the doohicky isn't staving off Cthulu's wrath, but merely to know that that is the purpose.
- HCIdivision17 11y ago
  To be sure, there are limits to one's sanity when over-applying this principle, but I also would apply it far past where many would stop. A simple explanation that doesn't quite fit needs yet more inquiry. Normally, the application pre-limits the number of things that may go wrong, and you can use that to save some effort. For example, I may not know if a pressure sensor's wiring diagram is correct enough to squelch Cthulhu's call, but since that has not bearing on if the vaccuum system's gases are pure, I also don't care. (That's the sort of thing HR and Operations to worry about.) Usually this meant digging in deep, questioning really basic stuff like "Are we sure this model is normally open or closed? Did the manufacturer forget to tell us?", and normally there would be clues or evidence to hint at the next round of questions. Eventually you'll have enough information that the evidence fits the questions, and there's no clear line of inquiry left. Life experience and just volume of work teaches one the limits of inquiry (old engineers can be shockingly good at this, to the point of appearing sloppy :) I once spent 6 hours overnight troubleshooting a confusing gas non-leak that ended up being the result of a default setting changing on a valve being replaced off-the-record by not-the-usual-guy. It gave me the confidence that this process does eventually get to the bottom of it, but it was a long, meandering path from miswired panels to out of date schematics in the wrong language to noting how clean the part was to know someone replaced it. All to dig out the missing tribal and undocumented information, proving the PLC was actually correct to interlock the whole machine out. (It's like knowing your program will halt - you can't prove it, but you can still be damn sure it will. At least until it doesn't ;)
akavel 11y ago
A corollary is that actual bugs tend to become the sturdiest, longest lasting fragments of code. Because they're by definition incorrect, so no one can really fully and correctly "describe why they're there", and thus people tend to feel afraid to fix the code ("dangerous and risky to fool with it"), because maybe that's not a bug? (and thus "someone might punish me later for touching this code")

JoshTriplett 11y ago

While that's entirely true, it's also true that any code covering an obscure corner case ought to document that corner case and why the code is needed. And similarly, any policy or law should be completely clear about what problem it wants to solve. That would make it far easier to maintain.

run4yourlives2 11y ago
This is kind of irrelevant though. Sure it should be documented, and sure the fence should have a nice notice of purpose posted right at the gate for everyone to see, but life doesn't work like that.
- Bartweiss 11y ago
  I'm not sure I'd go as far as irrelevant - rather, I would say that documentation is what you do to keep other people from needing the principle of charity. They're two directions on solving the same problem. As a maintainer you should assume good intentions, but as a creator you should work to clarify your intent.
  - run4yourlives2 11y ago
    Agreed, but irrelevant to this particular conversation, which is about how to handle a "fence" in the road where there is no obvious reason evident.
Bartweiss 11y ago
Documentation is essentially the proactive version of the idea for which the principle of charity is the reactive version. Assume that those who came before you had good reasons for their actions, and assume that those after you will be unable to identify any motivation you don't state explicitly. I'd be curious to see a strong legislative version of this - enshrining the spirit of the law in the text, and giving courts explicit rights to strike down laws which no longer fulfill their original intent. Done well, it's the sort of change which could have worked wonders on our legal system's constant failure to adapt to technological change. The Aereo suit, for instance, shouldn't have happened under any kind of intent-based legal system.
- JoshTriplett 11y ago
  > Assume that those who came before you had good reasons for their actions There's a limit to that assumption, though. I'm always inclined to assume that people had reasons, and that they looked good at the time, but without knowing what those reasons are, there's no way to know if the reasons are as good now as they were then, even if you make the charitable assumption that they were good reasons at the time. I would be a big fan of the idea that legislation had built-in turnover clauses, for instance, that required renewal every N years (for a value of N not much larger than the turnover rate of legislators). Which then means if you want something to persist, you would have to document your rationale for posterity, and convincingly argue that that rationale still applies. > I'd be curious to see a strong legislative version of this - enshrining the spirit of the law in the text, and giving courts explicit rights to strike down laws which no longer fulfill their original intent. I agree completely. Laws should state up front that "the purpose of this law is to ...", and for that matter explicitly state any other relevant considerations or side effects and whether they're considered beneficial, undesired, or simply neutral. That would mean there would have to be at least a pretense of a sensible motive, and that interpretations that don't serve that motive could be thrown out. > The Aereo suit, for instance, shouldn't have happened under any kind of intent-based legal system. It still could have, depending on the intent. The intent of copyright law, for instance, is supposed to be "we want more works produced, but we also want more works to enrich the public domain, so there's a tradeoff". The intent was never about authors and what they want; that's a means to an end. However, that rarely seems to be reflected in deliberations.

swanson 11y ago

This is an awesome comment, thank you for sharing. Do you know of any other resources/materials like this? (Specifically would love to learn more about these kind of principles as related to mechanical engineering or a factory/process setting)

malingo 11y ago
An amusing anecdote is the onion in the varnish: http://c2.com/cgi/wiki?OnionInTheVarnish http://c2.com/cgi/wiki?OnionInTheVarnish
HCIdivision17 11y ago
Foolishly, I don't really. I made the connection in some other thread on HN, and it's stuck with me. My advice is perhaps terrible: find yourself an old engineer and just do whatever it takes to be their friend and follow 'em like a puppy. It's sorta weird how effective it is to just be around people like that (and I think some PE licenses actually require apprenticeships for that reason). But I do have two formative things: Feynman's lecture on Cargo Cult Science is excellent, with this gem: "The first principle is that you must not fool yourself--and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other scientists. You just have to be honest in a conventional way after that... I'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen." - Feynman [0] I can't tell you how many times this has saved me in the field. Replace the word 'scientist' with '<YOUR DISCIPLINE HERE>' as needed. (And I think moreso for engineers than scientists, since safety absolutely requires this mentality.) And I really like the ideas in The Pragmatic Programmer [1]. More than anything specific, the idea of not being married to any particular concept or solution, but rather to pragmatically chose what is correct then for that circumstance helps a lot. The book is opinionated, but reasonable, and copying that pleasant tone is a fast way to make allies when solving problems in a group. And it's a pretty good book to boot. [0] http://neurotheory.columbia.edu/~ken/cargo_cult.html http://neurotheory.columbia.edu/~ken/cargo_cult.html (and is an HN favorite, to be sure) [1] https://pragprog.com/the-pragmatic-programmer https://pragprog.com/the-pragmatic-programmer (another HN favorite, though not always brought up in terms of engineering)

Bartweiss 11y ago

Chesterton's Fence should be one of the core principles of software development, and it calls to mind the famous "Never rewrite software" article. If you're refactoring, you can use unit tests and proofs of equivalence to demonstrate that your changes don't pose a threat. If you're rewriting a whole codebase, you're likely to wander down the same paths of "wait, the simple way doesn't work" that the person before you took. Even bafflingly small changes like removing always-false tests have been known to break code, which ought to inspire real hesitation any time you see "stupid" code written by a smart person.

loup-vaillant 11y ago
> Even bafflingly small changes like removing always-false tests have been known to break code Okay, how is this even possible? Reflection/pre-processing magic?
- barrkel 11y ago
  Compiler codegen bugs.
  - Gibbon1 11y ago
    I've had a few compiler bugs where, adding an if false or changing the order of an if test 'fixes' things. And the complement changing the code exposes a compiler bug. And also, new improved compiler results in code that's broken. Other issues I run into a fair amount is dealing with hardware/naked interrupts often involves a lot of subtle timing and read/write access issues. Sometimes this happens in code you don't own.
- brianpan 11y ago
  Another comment in this post: >I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices. https://news.ycombinator.com/item?id=10036050 https://news.ycombinator.com/item?id=10036050 I can also imagine methods with side-effects. The test is always false but a side-effect is necessary.

Too 11y ago

I worked in a similar setting, writing safety critical code. Any time we found code that was so dumb that it couldn't possibly be correct, without documenting why, we still did a blame to see when it was written, if the blame was older than the current source control system we did a blame in the previous one (this could be 10 year old code). Once we found when it was written we looked at any commit messages, if nothing obvious was written there we looked at general code movement around the time of the commit, we looked at any documents changed around the time of the commit, we looked at issue tracker tickets filed and closed around the time of the commit, we looked at test cases written around the time of the commit, test reports that had different results before/after. In essence we did everything in order to understand how the person thought when writing the code. This had always been a code base with very rigorous processes around it so explaining things by "he probably was lazy and let it slip by" was not a valid excuse before all other reasons had been investigated. Obvious "errors" like if(false) is a stupid example of this, why would someone commit if(false)? Is it supposed to be if(true)? Is it for debugging only or is it code that should actually be removed? Maybe it's used for other reasons by a preprocessing-tool that you are not aware of?

Bartweiss 11y ago
This is a great story/summary, and it underlines the value of being able to "hear from" the code's original author (either by contacting them, or preferably by referring to high-quality documentation saying "this looks stupid, here's why"). I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices. The stupider the "error", the more suspicion you should assign to its presence in any half-decent code.

wyager 11y ago

The principle of charity sounds extremely questionable; what is the purported benefit of suspending logical thought for the purposes of understanding something that may be wrong? I want to understand the idea logically, so I don't want to substitute in some second-rate folk understanding while I'm considering it.

Bartweiss 11y ago
The principle of charity is basically a way to approach new ideas arising from mindsets different than yours. The 'assumption of truth' step doesn't require us to believe anyone who walks up and says "A ^ ~A". Rather, it says that you shouldn't immediately reject a philosophy because it disagrees with your prior notions. The 'resolve contradictions' similarly doesn't mean that we have to overlook flawed claims. It's a tool to help learn an idea even if you don't get a perfect presentation of it. There may be a valuable concept available even if the person explaining it to you can't properly work through every detail. As an example, most people who could talk to you about evolution can't explain the development of eyes, but that doesn't mean you should assume evolution is bunk when you hear about it. The principle of charity says "there might be a good reason here, whether or not they can provide it". In short, the principle is an attempt to get value out of ideas you're presented with. That might mean you're engaging with a different idea than what you were actually presented with, but it gets you more insight. It's not something you want to use when faced with a concrete form of the document - it's not a reason to pass a bad-but-well-intentioned law.
5040 11y ago
The principle of charity asks you to grapple with the best possible version of an argument. If the one making the argument makes an obvious mistake, correct it and take on the corrected argument rather than the flawed one. Nowhere is logical thought suspended. The goal should be truth, so why fixate on small mistakes instead of fixing them and engaging with a sounder argument?
HCIdivision17 11y ago
It's not questionable, just good practice. And my experience tells me it's a Best Practice. `Bartweiss gives a good overview of it, but I'll share some advice I got from an engineering greybeard (which I most definitely am not). He had a great story to go with this, but the TLDR is that the PoC is the safe choice when applied to engineering: give a true, best-faith effort to prove the opposing view correct. (And best-faith is important: you can not approach it with bias, lest you waste everyone's time.) If you're right, then you'll find an irrefutable flaw in the engineering, and if you're wrong you've learned something new. If it sounds like a lot of effort, it is. But this is also utterly win-win. It's a way of assuring that you've been careful. Avoiding the humiliation of hubris is great if a detail of the implementation was missed at first glance. But you also will inevitably more fully understand the problem when you've failed to implement the opposing view; it also puts you in the excellent position to graciously be on the same side as your opponent and now you can sway your now-ally-in-war in their reasoning. In either way, your goal must be to solve the problem, and not merely "win" political points. Of course, there's crackpot theories and stupid ideas and foolish plans which should be dismissed with prejudice. But hopefully you're working in a professional environment where your coworkers really are trying their best to succeed. And even then, a serious engineer will still give the stupid ideas at least some (small) time of day, as you must have a reason for all decisions, even dismissals; as you become experienced, you'll be able to properly dismiss these faster and more precisely, but you'll still need to go through the process. That process is what separates the people who loudly proclaim they are smart and right from those who would testify in court they are right. (Incidentally, this is part of the reason why I get immensely frustrated with "idea people", as it takes much more work to flesh out their half-assed ideas into full-assed ideas. Non-engineers don't get that there's a huge amount of effort to constantly take everything and everyone seriously.)

Nacraile 11y ago

I'm going to dispute the "iff". Chesterton's fence is a useful idea to keep in mind, but it is flawed in that it is excessively conservative. It demands that you prove a negative, which is not reasonable in general. (How do you prove that that apparently useless doohicky isn't staving off Cthulu's wrath?). It's important to try to understand why something exists, but it is also important to understand that the reason often is that it was either unintentional or silly, but you won't be able to prove it because it isn't documented and the person responsible is gone/unknown.

taejo 11y ago
Chesterton's fence doesn't require you to prove that the doohicky isn't staving off Cthulu's wrath, but merely to know that that is the purpose.
HCIdivision17 11y ago
To be sure, there are limits to one's sanity when over-applying this principle, but I also would apply it far past where many would stop. A simple explanation that doesn't quite fit needs yet more inquiry. Normally, the application pre-limits the number of things that may go wrong, and you can use that to save some effort. For example, I may not know if a pressure sensor's wiring diagram is correct enough to squelch Cthulhu's call, but since that has not bearing on if the vaccuum system's gases are pure, I also don't care. (That's the sort of thing HR and Operations to worry about.) Usually this meant digging in deep, questioning really basic stuff like "Are we sure this model is normally open or closed? Did the manufacturer forget to tell us?", and normally there would be clues or evidence to hint at the next round of questions. Eventually you'll have enough information that the evidence fits the questions, and there's no clear line of inquiry left. Life experience and just volume of work teaches one the limits of inquiry (old engineers can be shockingly good at this, to the point of appearing sloppy :) I once spent 6 hours overnight troubleshooting a confusing gas non-leak that ended up being the result of a default setting changing on a valve being replaced off-the-record by not-the-usual-guy. It gave me the confidence that this process does eventually get to the bottom of it, but it was a long, meandering path from miswired panels to out of date schematics in the wrong language to noting how clean the part was to know someone replaced it. All to dig out the missing tribal and undocumented information, proving the PLC was actually correct to interlock the whole machine out. (It's like knowing your program will halt - you can't prove it, but you can still be damn sure it will. At least until it doesn't ;)

akavel 11y ago

A corollary is that actual bugs tend to become the sturdiest, longest lasting fragments of code. Because they're by definition incorrect, so no one can really fully and correctly "describe why they're there", and thus people tend to feel afraid to fix the code ("dangerous and risky to fool with it"), because maybe that's not a bug? (and thus "someone might punish me later for touching this code")