

If you can't remember why onions are in there, take 'em out. - franze
http://garry.posterous.com/if-you-cant-remember-why-onions-are-in-there

======
jsdalton
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."

~~~
mechanical_fish
_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.

~~~
5hoom
_"the longer the onions have been in the recipe, the longer the recipe has
evolved in the presence of onions."_

That is just an excellent explanation of why removing stuff from a working
system can be so dangerous. Thank you.

~~~
dotBen
And why we should write our recipes (code) carefully to imply intent such that
dependencies like this are not created unnecessarily. Consider:

"Add one onion", vs "Dip piece of onion in mixture until it begins to fry"

Latter clearly indicates no aspect of the recipe should be a dependency on the
onion or inherit properties from the onion as the onion will be removed before
runtime (consumption)

~~~
p0ckets
This still wouldn't be sufficient in mechanical_fish's example. Someone might
still remove the onions (and the needed proteins) after the introduction of
thermometers with the reasoning that this would be a "simple" and "well
understood" tweak.

------
othello
This piece of advice is quite at odds with another classic piece:

<http://www.joelonsoftware.com/articles/fog0000000069.html>

 _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._

~~~
hvs
That doesn't sound like it's at odds at all. The point of the article is that
you should investigate _why_ something was done in the past so that you don't
keep repeating the same thing even when it isn't necessary anymore. All of the
things in your quote are still required and shouldn't be removed.

~~~
masklinn
It's at odds with the title, and in line with the content of TFA. OP used a
title which has no bearing in the article he linked.

~~~
mcantor
Well, "If you don't remember why onions are in there, investigate carefully as
to why they were added in the first place, then take 'em out if they're no
longer relevant" wouldn't fit in the title!

------
rhplus
There was a This American Life episode a little while back that had a counter
example to this anecdote: sometimes there is something in your process that
makes your product special but you don't even know it until it disappears.

Audio here[1] at 34:30. A brief summary found here[2]:

"Jim Bodman, Chairman of Vienna Sausage Co. in Chicago tells the story of how
the company built a brand new, state-of-the-art facility in 1970, replacing
their old factory, which was actually a warren of buildings on Chicago's south
side that was built up by gradually buying up buildings over the course of 70
years, until the factory complex occupied an entire city block. Once they
moved into their fancy new digs, however, they faced a problem: the hot dogs
weren't coming out the same. They didn't have the same distinctive red color
or desired snap. They couldn't figure out what was wrong, since the
ingredients, spices, cooking time, everything was the same.

After a year and a half, they still haven't figured it out...until one night,
when some guys from the plant are out at a bar, reminiscing over drinks about
the old days in the former plant. They start talking about Irving, a fixture
at the old plant who knew everyone, whose job was to take the uncooked
sausages to the smokehouse. But, given the "Rube Goldberg" layout of the old
factory, it took Irving half an hour on a circuitous route to get from A to B.
And they realized: Irving & his trip was the missing secret ingredient."

[1] [http://www.thisamericanlife.org/radio-
archives/episode/241/2...](http://www.thisamericanlife.org/radio-
archives/episode/241/20-acts-in-60-minutes) (audio at 34:30)

[2] [http://theatreeastnyc.blogspot.com/2011/10/how-sausage-er-
th...](http://theatreeastnyc.blogspot.com/2011/10/how-sausage-er-theatre-is-
made.html)

------
byrneseyeview
GK Chesterton tells a similar, but sort of contradictory, story:

 _In the matter of reforming things, as distinct from deforming them, there is
one plain and simple principle; a principle which will probably be called a
paradox. There exists in such a case a certain institution or law; let us say,
for the sake of simplicity, a fence or gate erected across a road. The more
modern type of reformer goes gaily up to it and says, "I don't see the use of
this; let us clear it away." To which the more intelligent type of reformer
will do well to answer: "If you don't see the use of it, I certainly won't let
you clear it away. Go away and think. Then, when you can come back and tell me
that you do see the use of it, I may allow you to destroy it."_

In most technology fields, it seems like Onion Theory works: we can gradually
get rid of the hacks we used to get round limitations. But when you're dealing
with people and institutions, Fence Theory dominates: human interactions have
lots of complicated nth-order effects.

Onion Theory and Fence Theory are deeply similar. In both cases, the point is:
be aware of practices that don't make sense. Either they illustrate long-ago
hacks and compromises, or they tell you something important but non-obvious
about the nature of what you're doing.

------
pg
The advice I took from Levi's story is: consider the possibility that things
you take for granted as necessary actually aren't. They could be mistakes, or
artifacts of limitations that have since disappeared.

(It's particularly useful for startups to notice the latter, incidentally. A
lot of existing businesses turn out to be artifacts of limitations that have
since disappeared. E.g. hotels are to some extent a hack to get around the
fact that it used to be impossible to search all the available space in the
city you wanted to visit. If you built a whole building full of bedrooms, you
could afford to pay to advertise it and to pay someone to work full time
taking reservations.)

~~~
eru
There are also economies of scale in stuff like cleaning. And some people want
quality control.

------
kinofcain
I think the moral of the story for programmers _should_ be:

If you're putting something in your code that looks like a vegetable, please
put a comment on it.

Ten months down the rode you won't remember why that silly looking hack is
there and neither will anyone else. It might not be applicable anymore and it
might be safe to remove, or it might be holding together something critical.

------
dodedo
Feynman used the term "cargo cult science", and others later used the term
"cargo cult programming" to describe this.

<http://en.wikipedia.org/wiki/Cargo_cult>

Several weeks ago on HN I came across this slideshow:
<http://www.slideshare.net/olvemaudal/deep-c> which sparked some debate as to
the merits of deep, complete understanding of one's environment. I believe
that those who do not have a broad understanding invent their own miniature
cargo cult to get by -- or perhaps it is that they are willing to cargo cult
and therefore do not develop a deep understanding?

Whatever the case, it's incredibly common in the world of software.

------
the_mat
There's a dangerous flip side to this: In my experience just about all
programmers want to remove things from code that they don't understand or see
the reason for. Why is that weird check there? Who thought it was a good idea
to allocate memory that way? Very often there ARE good reasons for those
decisions, and they can stem from bug fixes or odd special cases that may not
be obvious..

Moral: Be careful.

~~~
hvs
Right, which is why you don't just remove the onion because you feel like it.
In that story, he found out _why_ they used to put the onion in and determined
it was no longer necessary.

Moral: if you don't understand code, don't change it, understand it.

~~~
gbog
> understand it.

This has been said in some replies in this tree, but sometime you can take the
piece of code you don't understand as a black box, and bridge its behavior
with new code, comparing both outputs during a few iterations, then remove old
code.

------
bradleyland
If you can't remember why onions are in there, you probably need better
documentation.

~~~
DanielStraight
Yes!

To me, this is the real point of the story. If you are doing anything at all
non-obvious, then eventually it will make no sense at all, so write down why
you did it.

~~~
MichaelApproved
The trouble is, many things are obvious when we're doing it. It becomes non-
obvious months/years later. Document as much as possible.

~~~
DanielStraight
Good point.

I think it would be good to ask yourself two questions every time you write a
piece of code.

1\. Is it obvious what this code is doing? (For example, i+=1 is always
obvious, at least in regards to _what_ it is doing.)

2\. Is it obvious why I'm doing this? (If you're in a loop, i+=1 is pretty
obvious as to the _why_ as well, but elsewhere, it might require
explanation... and you probably shouldn't be using the variable name i outside
a loop, but that's not the point I'm trying to make here.)

For some idea of what this looks like, I've been working on a piece of code
today that uses an external program through its API to load a file and make
some changes to it. I didn't document the 3-4 lines it takes to load the file
and get the object I need. Why? Because it's just how you load a file. Anyone
could figure out that out from the documentation. It's already clear what I'm
doing: loading a file. And why I would want to do that is obvious given the
intent of the program: the whole program is created to perform some operations
on files.

I do, however, document why I'm changing the working directory of the program
to the folder the file is in. Because the program always saves to its working
directory when you call Save from the API, which is not at all obvious or
documented in the API.

For one rule (certainly not the only one): anything you had to figure out
through trial and error is non-obvious.

It might be interested to collect some example of things programmers decided
to or not to document and explanations for those decisions.

~~~
ajross
My experience over a long career of fixing bugs is that it just doesn't
matter. Comment-free code doesn't tell you why it does what it does.
"Well"-commented code devolves into lies over time. Hard bugs are just hard.

What _does_ help is keeping the voodoo out in the first place by reducing the
"non-obvious" bits to an absolute minimum. Which of course is isomorphic to
saying that "great code has less bugs". Not exactly profound. But notably it
has nothing to do with commenting or documentation, per se.

------
steve8918
Funny story, the 3rd job I had was at this large telecommunications company. I
was doing consulting, but one of the jobs I had to do was make sure that these
very important reports were generated. They had to be printed out and sent
over the interoffice mail.

I figured, why not generate the reports programmatically and stick them on an
intranet website (this was 1999 so "intranets" were becoming a buzzword). I
asked my boss, he said okay go contact the people who need the report and see
if they are okay with that.

I called the person A that normally got the reports, and they said "Oh, I
don't need them, I pass them off to B". So then I called B and they said they
passed it to C. This went on for about 5 people, and then it turned out that
no one needed the reports. It was just something that was ingrained into the
process, but no one actually needed.

The funny thing is that because no one had ownership, I could neither change
the process, nor get the reports from being printed in the first place. Truly
Office Space-esque

------
edw519
Reminds me of this old story:

A religious scholar was telling his wife about the interesting discussion in
class one day.

"We were attributing the reason for removing the chicken's legs before cooking
it for soup."

"Reb Schalcter said it was to follow the dietary laws laid out in Leviticus."

"Reb Abraham said it was to help us retain our compassion because an innocent
animal had to suffer for our benefit."

"Reb Zalman said it was because the legs were most likely to be diseased."

"I said that it was to remind us that the world, like the chicken, is broken."

"What do you think?"

His wife responded, "So that it fits in the pot."

~~~
mrsebastian
This is basically the origin of all religions, especially 'modern'
monotheistic ones.

Good, sensible ideas (at the time!) get codified. Throw in a charismatic
leader of some kind who (apparently) goes around trumpeting these smart ideas.
Voila, religion.

~~~
Alex3917
Any dead religion is by definition not a modern religion. If you look at
religious movements started within the last 50 years in the U.S., there are
few if any that fit that pattern.

------
some_g
Two paragraphs of agreement with an old pg article. Why is this getting
upvoted?

------
pbhjpbhj
Of course the onion will show you if the temperature sensors are working
correctly ...

------
nickolai
This piece of advice does not apply to legacy systems. There is a lot of stuff
in there that nobody knows how it works or why it is in there, yet attempting
to throw it out has led to so many disasters in the past that no one dares to
even think about removing it. Of course there is no budget or political will
to investigate - money comes in just fine even with the onion in the varnish.

------
xbryanx
If you can't remember why the onions are in there you've written poor
documentation.

------
contextfree
What if you can't remember why you decided to adopt "If you can't remember why
onions are in there, take 'em out" as one of your personal guiding maxims?

------
GlennS
But onions go with everything and are delicious

------
amandalim89
So true. The hardest part is taking away features from your own product. We
need to learn to let go of non-crucial features. built. launch fast. iterate
faster.

------
malkia
Hopefully someone would remember why circumcision is done always by certain
people following certain traditions, religious rules...

------
zachrose
Can anyone explain in more detail how this relates to Arc and Lisp?

------
ThaddeusQuay2
<http://youtube.com/watch?v=KZeiSKnhOBc> (5 Monkeys)

