related unwork
I had an interesting conversation with garth about "related work" sections in research papers a couple weeks ago, and it's kind of a testament to the reason I've become so discouraged by the "publication-driven culture" of systems (and presumably other) research. I asked him, why does this paper put the related work section at the front, while most of the sosp/osdi/etc papers we've read this semester put them at the back?
garth explained: putting the related work section at the front (after the intro, before the main content) is a more "honest" way of presenting your work, as though: "here is what has already been done. now, here is what we have done in addition to it." putting the related work at the back (between evaluation and conclusion) is just a disingenuous way of making your work look better, like "we have done all this stuff, including original groundwork; oh, and also, here's some other stuff that we took some similar ideas from."
but in conferences (at least, especially in sosp/osdi), it is such an accepted convention for people to put the related work section at the end (that is, it can't be grounds for rejecting a paper, because every paper does it) that it is just a way of earning free points towards making your work look better.
along the same lines, i've heard several times from maurer that he wishes conferences would mandate people releasing the source code for their projects. keeping your implementation private helps you get more publications in the future, since nobody will race you to them, but it hurts the field both by letting you pass off shitty implementation and shaky-at-best results for genuine progress and also by making anybody else who wants to contribute repeat a bunch of boring groundwork before they can do anything actually new.
tragedy of the commons...
garth explained: putting the related work section at the front (after the intro, before the main content) is a more "honest" way of presenting your work, as though: "here is what has already been done. now, here is what we have done in addition to it." putting the related work at the back (between evaluation and conclusion) is just a disingenuous way of making your work look better, like "we have done all this stuff, including original groundwork; oh, and also, here's some other stuff that we took some similar ideas from."
but in conferences (at least, especially in sosp/osdi), it is such an accepted convention for people to put the related work section at the end (that is, it can't be grounds for rejecting a paper, because every paper does it) that it is just a way of earning free points towards making your work look better.
along the same lines, i've heard several times from maurer that he wishes conferences would mandate people releasing the source code for their projects. keeping your implementation private helps you get more publications in the future, since nobody will race you to them, but it hurts the field both by letting you pass off shitty implementation and shaky-at-best results for genuine progress and also by making anybody else who wants to contribute repeat a bunch of boring groundwork before they can do anything actually new.
tragedy of the commons...