10 ms·

Cute litte story, but the moral the author takes away from it is actually wrong. The factory didn't remove the onions from the recipe because no one could reme

Cute litte story, but the moral the author takes away from it is actually wrong. The factory didn't remove the onions from the recipe because no one could remember why they were there. They were removed because Levi asked why they were there, and when no one remembered, he investigated the original purpose of the onions and determined after that investigation that they were no longer needed. I'm sure many of us have been bitten by this as developers. You see a few lines of codes or a feature and you have no idea why it's there, so you remove it. What happens? Random, seemingly unrelated application starts failing or angry customer calls wondering why some feature is no longer available. Whoops... So my takeaway from this story was actually quite different from the author's. I took: "Before you remove the onions, make sure you understand why they were added in the first place."

loup-vaillant 15y ago
If the priority is to not break anything, sure, don't fix what's not broken. Now every piece of code which is there for no know reason remains a problem. If you want to keep the code base simple, better remove either the code or your confusion (add a comment, refactor, whatever).
- hvs 15y ago
  You should never remove code that you don't understand. And when isn't it a priority to "not break anything?"
  - yxhuvud 15y ago
    Yes you should. It is often the simplest way of discovering why it is there - you see what part will break.
    - polymatter 15y ago
      I think you mean this as part of the investigation in what this code does. That is, after setting up a test/dummy system, you remove the code, run your tests and try to break it. Perhaps sticking in breakpoints or print lines or whatever.. I doubt you really mean to experiment on the business-critical live system. Thats unlikely to be very effective anyway. The most obscure code is often a bug fix for some really obscure bugs. Maybe it fixes some weird bug in Swedish XP SP1, or something which you don't find just by removing it and testing. Situation depending, you will need to actually read and understand the code and investigate properly.
      - yxhuvud 15y ago
        Obviously, it is not a tactic to use on a live production system. On the other hand, no programming at all at a live system is the prudent way of doing it. Good test coverage help a lot here though - remove something and you'll get a set of failing tests to investigate.
    - grannyg00se 15y ago
      Or you notice nothing breaks so you leave it out, joyfully congratulating yourself that you reduced total LOC count by one. Then six month later things start breaking and you have no idea why.
      - gbog 15y ago
        Refactoring and removing code needs courage and tact, but sometime it needs to be done. If you have a database that is not properly normalized, the more client code you add to it, the harder it is to normalize later. The biggest problem with refactoring and removing code is to explain it to non-techy project managers. If you say that the code or the design is bad, you are saying the guys behind it are bad (you or the previous team), which is not very tactful. I usually try to explain that a software system is a living thing, that need some regular washing up. Also, it is possible to explain that the next features or optimizations will take less time to implement after refactoring.
        yxhuvud 15y ago
        I tend to blame myself. "I didn't fully understand the problem space when I first wrote it, and now I have to rewrite it because it is a horrible mess and too complex to maintain". Works surprisingly often.
  - mcantor 15y ago
    If our highest priority was always "Don't break anything", we would never ship to production after the first move. "Make it better" is often a higher priority.
  - loup-vaillant 15y ago
    Whenever your product is in for the long run. For those cases, better temporarily break it than eventually being unable to manage it at all. That line of code no one understand is a technical debt. Sometimes, it is better to pay the debt right now. I'm currently working on a 2 millions LOC program which never paid its dammed debts, and I weep every day before this holly Big Ball of Mud.
  - jeffdavis 15y ago
    "You should never remove code that you don't understand." Never is a long time. It's fairly easy for low-skill developers to write code that's time-consuming for high-skill developers to understand. In fact, making simple things hard to understand is pretty much the definition of bad code. So, you use your judgement. If it's a particularly subtle and important part of the code, spend the extra time to make sure you're not missing anything. If it's not, then just rip it out and don't waste time in a maze of strange control flow, redundant code, useless invariants, and confusing assumptions.
- masklinn 15y ago
  > If the priority is to not break anything, sure, don't fix what's not broken. The issue generally arises because things are broken, investigation leads to a piece of code which creates the breakage (everything is perfect before, things are broken after), nothing seems to use it (the project is naturally pretty much void of automated tests), you remove the code, it fixes the issue, and then you learn that prod has started failing hard.
masklinn 15y ago
> I'm sure many of us have been bitten by this as developers. You see a few lines of codes or a feature and you have no idea why it's there, so you remove it. What happens? Random, seemingly unrelated application starts failing or angry customer calls wondering why some feature is no longer available. Whoops... Yep. Tells me OP is not a developer, and has not read the article he linked. Because the title makes no sense at all.
mechanical_fish 15y ago
Before you remove the onions, make sure you understand why they were added in the first place. Unfortunately, while this is correct, it is nowhere near strong enough. Just because you know the initial hypothesis that drove someone to throw the onions in, doesn't mean you know what the onions are actually doing. The onions are interacting with all the other ingredients. Onions are more complicated than you think. Before you remove the onions you must understand what they are actually doing in your recipe, not merely what you think they are doing... or you must be prepared to find out. Because even very tiny systems are generally too complicated for you to fully understand, you usually have to settle for science: You must have good enough test coverage to detect any breakage as soon as possible after the onions go out, so that you may frantically throw the onions back in and then go back to the drawing board. And the longer the onions have been in the recipe, the longer the recipe has evolved in the presence of onions. Take the onions out and all the other changes that have happened since the onions went in might have to be tweaked. Oh, the subtle things you could find. Here is what can happen: You'll take out the onions, and then five years later your customers will complain that your company's red paint has started peeling, ten years ahead of the fifteen-year warranty period. Oh, no. You call an all-hands meeting of your QA team. They spend months doing expensive research, while your product engineers fly from city to city trying to pacify the increasingly irate customers. Eventually the scientists find that the paint can be fixed by mixing in some kind of protein or other. But why did the paint used to work? Oops, the onions had protein in them! Sure enough, if you throw in some special Essence Of Onion Protein compound the problem goes away. Great. Now all you have to do is issue a field recall of about six years worth of your product. You will bring this story to your CEO and the shareholders, and they will ask why you didn't just pay for some onions? Or, if removing the onions was critically important, why you didn't run a small set of onion-free test batches on a parallel process line and then put those batches through lots of tests, both in the lab and in the field, before making the change? I've worked as a semiconductor engineer, specifically in charge of diagnosing problems that arose in the field, so believe me when I tell you that I've seen "simple", "well understood" little tweaks in a semiconductor processing recipe cost companies millions of dollars and one hell of a lot of stress. I've also lost six months of my grad student career to one specific bad step in a recipe. Once you get a working recipe you do not change a thing without a specific plan to thoroughly measure and document the effect of that change. Find someone from Intel and ask them how this works: I've heard that you can't so much as touch a knob in Intel's fabs without a signed change order.
hugh3 15y ago
Another classic story which illustrates your point: the "Magic/More Magic" switch. http://catb.org/jargon/html/magic-story.html http://catb.org/jargon/html/magic-story.html Closer examination revealed that the switch had only one wire running to it! The other end of the wire did disappear into the maze of wires inside the computer, but it's a basic fact of electricity that a switch can't do anything unless there are two wires connected to it. This switch had a wire connected on one side and no wire on its other side. It was clear that this switch was someone's idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it. The computer instantly crashed.
CapitalistCartr 15y ago
The story sounds to me like a call to document thoroughly. To avoid the onions write down the reasoning with every step.
vilhelm_s 15y ago
"Don't ever take a fence down until you know why it was put up." --Robert Frost
- dtby 15y ago
  For anyone who might be reading with showdead on: While a lot of people seem to attribute this quote to Robert Frost, possibly because of his poem "Mending Wall", this is actually from "The Thing" by G. K. Chesterton. http://www.gkc.org.uk/gkc/books/The_Thing.txt http://www.gkc.org.uk/gkc/books/The_Thing.txt

loup-vaillant 15y ago

If the priority is to not break anything, sure, don't fix what's not broken. Now every piece of code which is there for no know reason remains a problem. If you want to keep the code base simple, better remove either the code or your confusion (add a comment, refactor, whatever).

hvs 15y ago
You should never remove code that you don't understand. And when isn't it a priority to "not break anything?"
- yxhuvud 15y ago
  Yes you should. It is often the simplest way of discovering why it is there - you see what part will break.
  - polymatter 15y ago
    I think you mean this as part of the investigation in what this code does. That is, after setting up a test/dummy system, you remove the code, run your tests and try to break it. Perhaps sticking in breakpoints or print lines or whatever.. I doubt you really mean to experiment on the business-critical live system. Thats unlikely to be very effective anyway. The most obscure code is often a bug fix for some really obscure bugs. Maybe it fixes some weird bug in Swedish XP SP1, or something which you don't find just by removing it and testing. Situation depending, you will need to actually read and understand the code and investigate properly.
    - yxhuvud 15y ago
      Obviously, it is not a tactic to use on a live production system. On the other hand, no programming at all at a live system is the prudent way of doing it. Good test coverage help a lot here though - remove something and you'll get a set of failing tests to investigate.
  - grannyg00se 15y ago
    Or you notice nothing breaks so you leave it out, joyfully congratulating yourself that you reduced total LOC count by one. Then six month later things start breaking and you have no idea why.
    - gbog 15y ago
      Refactoring and removing code needs courage and tact, but sometime it needs to be done. If you have a database that is not properly normalized, the more client code you add to it, the harder it is to normalize later. The biggest problem with refactoring and removing code is to explain it to non-techy project managers. If you say that the code or the design is bad, you are saying the guys behind it are bad (you or the previous team), which is not very tactful. I usually try to explain that a software system is a living thing, that need some regular washing up. Also, it is possible to explain that the next features or optimizations will take less time to implement after refactoring.
      - yxhuvud 15y ago
        I tend to blame myself. "I didn't fully understand the problem space when I first wrote it, and now I have to rewrite it because it is a horrible mess and too complex to maintain". Works surprisingly often.
- mcantor 15y ago
  If our highest priority was always "Don't break anything", we would never ship to production after the first move. "Make it better" is often a higher priority.
- loup-vaillant 15y ago
  Whenever your product is in for the long run. For those cases, better temporarily break it than eventually being unable to manage it at all. That line of code no one understand is a technical debt. Sometimes, it is better to pay the debt right now. I'm currently working on a 2 millions LOC program which never paid its dammed debts, and I weep every day before this holly Big Ball of Mud.
- jeffdavis 15y ago
  "You should never remove code that you don't understand." Never is a long time. It's fairly easy for low-skill developers to write code that's time-consuming for high-skill developers to understand. In fact, making simple things hard to understand is pretty much the definition of bad code. So, you use your judgement. If it's a particularly subtle and important part of the code, spend the extra time to make sure you're not missing anything. If it's not, then just rip it out and don't waste time in a maze of strange control flow, redundant code, useless invariants, and confusing assumptions.
masklinn 15y ago
> If the priority is to not break anything, sure, don't fix what's not broken. The issue generally arises because things are broken, investigation leads to a piece of code which creates the breakage (everything is perfect before, things are broken after), nothing seems to use it (the project is naturally pretty much void of automated tests), you remove the code, it fixes the issue, and then you learn that prod has started failing hard.

masklinn 15y ago

> I'm sure many of us have been bitten by this as developers. You see a few lines of codes or a feature and you have no idea why it's there, so you remove it. What happens? Random, seemingly unrelated application starts failing or angry customer calls wondering why some feature is no longer available. Whoops... Yep. Tells me OP is not a developer, and has not read the article he linked. Because the title makes no sense at all.

mechanical_fish 15y ago

Before you remove the onions, make sure you understand why they were added in the first place. Unfortunately, while this is correct, it is nowhere near strong enough. Just because you know the initial hypothesis that drove someone to throw the onions in, doesn't mean you know what the onions are actually doing. The onions are interacting with all the other ingredients. Onions are more complicated than you think. Before you remove the onions you must understand what they are actually doing in your recipe, not merely what you think they are doing... or you must be prepared to find out. Because even very tiny systems are generally too complicated for you to fully understand, you usually have to settle for science: You must have good enough test coverage to detect any breakage as soon as possible after the onions go out, so that you may frantically throw the onions back in and then go back to the drawing board. And the longer the onions have been in the recipe, the longer the recipe has evolved in the presence of onions. Take the onions out and all the other changes that have happened since the onions went in might have to be tweaked. Oh, the subtle things you could find. Here is what can happen: You'll take out the onions, and then five years later your customers will complain that your company's red paint has started peeling, ten years ahead of the fifteen-year warranty period. Oh, no. You call an all-hands meeting of your QA team. They spend months doing expensive research, while your product engineers fly from city to city trying to pacify the increasingly irate customers. Eventually the scientists find that the paint can be fixed by mixing in some kind of protein or other. But why did the paint used to work? Oops, the onions had protein in them! Sure enough, if you throw in some special Essence Of Onion Protein compound the problem goes away. Great. Now all you have to do is issue a field recall of about six years worth of your product. You will bring this story to your CEO and the shareholders, and they will ask why you didn't just pay for some onions? Or, if removing the onions was critically important, why you didn't run a small set of onion-free test batches on a parallel process line and then put those batches through lots of tests, both in the lab and in the field, before making the change? I've worked as a semiconductor engineer, specifically in charge of diagnosing problems that arose in the field, so believe me when I tell you that I've seen "simple", "well understood" little tweaks in a semiconductor processing recipe cost companies millions of dollars and one hell of a lot of stress. I've also lost six months of my grad student career to one specific bad step in a recipe. Once you get a working recipe you do not change a thing without a specific plan to thoroughly measure and document the effect of that change. Find someone from Intel and ask them how this works: I've heard that you can't so much as touch a knob in Intel's fabs without a signed change order.

hugh3 15y ago

Another classic story which illustrates your point: the "Magic/More Magic" switch. http://catb.org/jargon/html/magic-story.html http://catb.org/jargon/html/magic-story.html Closer examination revealed that the switch had only one wire running to it! The other end of the wire did disappear into the maze of wires inside the computer, but it's a basic fact of electricity that a switch can't do anything unless there are two wires connected to it. This switch had a wire connected on one side and no wire on its other side. It was clear that this switch was someone's idea of a silly joke. Convinced by our reasoning that the switch was inoperative, we flipped it. The computer instantly crashed.

CapitalistCartr 15y ago

The story sounds to me like a call to document thoroughly. To avoid the onions write down the reasoning with every step.

vilhelm_s 15y ago

"Don't ever take a fence down until you know why it was put up." --Robert Frost

dtby 15y ago
For anyone who might be reading with showdead on: While a lot of people seem to attribute this quote to Robert Frost, possibly because of his poem "Mending Wall", this is actually from "The Thing" by G. K. Chesterton. http://www.gkc.org.uk/gkc/books/The_Thing.txt http://www.gkc.org.uk/gkc/books/The_Thing.txt