8 ms·

If you can't remember why onions are in there, take 'em out.

151 points by franze 15y ago

the_mat 15y ago
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 15y ago
  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 15y ago
    > 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.
jsdalton 15y ago
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.
      - 15y ago
othello 15y ago
This piece of advice is quite at odds with another classic piece: http://www.joelonsoftware.com/articles/fog0000000069.html 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 15y ago
  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 15y ago
    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 15y ago
      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!
- seltzered_ 15y ago
  I like to say that these are the ugly nuances where code should be commented well.
  - 15y ago
bradleyland 15y ago
If you can't remember why onions are in there, you probably need better documentation.
- DanielStraight 15y ago
  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 15y ago
    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 15y ago
      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.
edw519 15y ago
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."
- Vivtek 15y ago
  I heard a similar one, about a woman who had learned from her mother always to cut the ends off the roast before putting it in the oven. One day, teaching her daughter about how to cook a roast, her daughter asked why, and she realized she didn't know - so she went to her mother. Her mother said, "I always thought it was for the taste, but I learned it from your grandmother; we should ask." So they asked the grandmother, who said, "Oh, when your father and I got married, all we had was a very small roasting pan, so I cut off the ends of the roast so it would fit."
- mrsebastian 15y ago
  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 15y ago
    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.
    - deleted 15y ago
      [deleted]
    - deleted 15y ago
deleted 15y ago
[deleted]
GlennS 15y ago
But onions go with everything and are delicious
dodedo 15y ago
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 http://en.wikipedia.org/wiki/Cargo_cult Several weeks ago on HN I came across this slideshow: http://www.slideshare.net/olvemaudal/deep-c 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.
kinofcain 15y ago
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.
pbhjpbhj 15y ago
Of course the onion will show you if the temperature sensors are working correctly ...
xbryanx 15y ago
If you can't remember why the onions are in there you've written poor documentation.
nickolai 15y ago
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.
some_g 15y ago
Two paragraphs of agreement with an old pg article. Why is this getting upvoted?
rhplus 15y ago
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/20-acts-in-60-minutes http://www.thisamericanlife.org/radio-archives/episode/241/2... (audio at 34:30) [2] http://theatreeastnyc.blogspot.com/2011/10/how-sausage-er-theatre-is-made.html http://theatreeastnyc.blogspot.com/2011/10/how-sausage-er-th...
pg 15y ago
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 15y ago
  There are also economies of scale in stuff like cleaning. And some people want quality control.
byrneseyeview 15y ago
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.
malkia 15y ago
Hopefully someone would remember why circumcision is done always by certain people following certain traditions, religious rules...
contextfree 15y ago
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?
amandalim89 15y ago
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.
ThaddeusQuay2 15y ago
http://youtube.com/watch?v=KZeiSKnhOBc http://youtube.com/watch?v=KZeiSKnhOBc (5 Monkeys)
steve8918 15y ago
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
zachrose 15y ago
Can anyone explain in more detail how this relates to Arc and Lisp?

151 points by franze 15y ago

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 15y ago
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 15y ago
  > 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.

jsdalton 15y ago

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.
    - 15y ago

othello 15y ago

This piece of advice is quite at odds with another classic piece: http://www.joelonsoftware.com/articles/fog0000000069.html 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 15y ago
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 15y ago
  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 15y ago
    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!
seltzered_ 15y ago
I like to say that these are the ugly nuances where code should be commented well.
- 15y ago

bradleyland 15y ago

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

DanielStraight 15y ago
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 15y ago
  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 15y ago
    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.

edw519 15y ago

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

Vivtek 15y ago
I heard a similar one, about a woman who had learned from her mother always to cut the ends off the roast before putting it in the oven. One day, teaching her daughter about how to cook a roast, her daughter asked why, and she realized she didn't know - so she went to her mother. Her mother said, "I always thought it was for the taste, but I learned it from your grandmother; we should ask." So they asked the grandmother, who said, "Oh, when your father and I got married, all we had was a very small roasting pan, so I cut off the ends of the roast so it would fit."
mrsebastian 15y ago
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 15y ago
  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.
  - deleted 15y ago
    [deleted]
  - deleted 15y ago

deleted 15y ago

[deleted]

GlennS 15y ago

But onions go with everything and are delicious

dodedo 15y ago

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 http://en.wikipedia.org/wiki/Cargo_cult Several weeks ago on HN I came across this slideshow: http://www.slideshare.net/olvemaudal/deep-c 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.

kinofcain 15y ago

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.

pbhjpbhj 15y ago

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

xbryanx 15y ago

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

nickolai 15y ago

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.

some_g 15y ago

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

rhplus 15y ago

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/20-acts-in-60-minutes http://www.thisamericanlife.org/radio-archives/episode/241/2... (audio at 34:30) [2] http://theatreeastnyc.blogspot.com/2011/10/how-sausage-er-theatre-is-made.html http://theatreeastnyc.blogspot.com/2011/10/how-sausage-er-th...

pg 15y ago

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 15y ago
There are also economies of scale in stuff like cleaning. And some people want quality control.

byrneseyeview 15y ago

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.

malkia 15y ago

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

contextfree 15y ago

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?

amandalim89 15y ago

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.

ThaddeusQuay2 15y ago

http://youtube.com/watch?v=KZeiSKnhOBc http://youtube.com/watch?v=KZeiSKnhOBc (5 Monkeys)

steve8918 15y ago

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

zachrose 15y ago

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