1

I'm new to this. I've written research papers before, but never one about a computer-science topic. So, I was wondering how exactly I should approach the methods and results section, as it seems more natural to simply do it all in one section, explaining how I did what I did and what I found for each step of my research. I'd appreciate some advice!

Vivaan Singhvi
  • 97
  • 1
  • 5
  • 3
    Before you write papers, you should read them. What do other people do in their papers? – Bryan Krause Jul 20 '23 at 14:42
  • Define 'written research papers' before - the structure and language of a technical journal article bears little resemblance to any paper you wrote in, say, your undergraduate degree. It is just a different style of writing. – Jon Custer Jul 20 '23 at 19:36

2 Answers2

1

In my experience, how to organize the sections for a computer science paper depends a lot on the conference or journal that you're sending it to.

With "computer science native" organizations like IEEE and ACM, there is typically free choice allowed for section titles, and thus no need to use a "methods/results" format. I'll thus often end up with section titles like "Architecture", "Analysis", and "Experimental Validation", organizing things however I think will be clearest for a reader. This is what I recommend doing whenever possible.

Unfortunately, many "non-native" journals, such as those with biology or chemistry roots, will force you to map your paper onto a Procrustean bed of "Methods/Results/Discussion" or even putting the Results first and the Methods last. This can be really problematic if you view an architecture or algorithm as a method, because then you'd be presenting experiments with the algorithm before you presented the algorithm!

In this case, it helps to realize that in computer science the development of a "method" like an architecture or algorithm is itself a result! I thus tend to deal with the "methods/results" format by using the same structure as I would in a computer science paper, but turning all the sections besides Introduction and Discussion be subsections of "Results". The "Methods" section is then reserved only for the not-very-interesting details somebody will only need to know if they are trying to reproduce identical experimental results. For an example of doing this, see this recent paper of mine on a software tool for biology.

jakebeal
  • 187,714
  • 41
  • 655
  • 920
-1

Some fields, specifically math and CS, aren't like others and so it is natural to structure research result papers differently.

But the methods section should say something about how your program/system architecture differs from the standard techniques applied to your problem. The results section should show how your results are an improvement (or not) over the standard. Even if you don't show an improvement, you can give an analysis of how the new technique fails and still contribute to the literature. Negative knowledge is still knowledge, though you haven't indicated that is the case here.

And note that even small improvements can be important if the means to that end are novel and can influence future research.

But, assuming you have advanced the art say both how and why in the results, and maybe the conclusions, section.

Buffy
  • 363,966
  • 84
  • 956
  • 1,406
  • I strongly disagree with your second paragraph, because of the "results before methods" inversion that many journals require, as mentioned in my answer. If you read non-CS papers in these journals, you will find that their equivalent "architecture" materials are also in the results section! – jakebeal Aug 19 '23 at 15:58