How to avoid disrupting the narrative in a scientific paper when you have done too much work

Question

I have been working on a project for almost a year now. This project involves the implementation of a computational method to calculate material properties and the application to different material systems. I have also done original modifications to the method during the course of the implementation.

At the moment I am in the process of writing down the details of the implementation and the results of my calculations. I have envisioned that the best way to break down the large amount of work that has been done is to write three papers. Chronologically: 1) one with the improved methodology with pertinent application results, 2) another one with the implementation details and 3) a final one focusing only on application of the code to a very interesting set of systems.

I think that writing papers 2) and 3) will become easier as I can simply refer the reader for details to 1) and 1) & 2), respectively, but I am having quite a bit of trouble finding the right narrative for the first paper, since I want to focus on the big picture of the theory and methodology but the little details of the implementation seem to constantly get in the way. This comes in the way of "we are trying to achieve this big objective A but in the actual implementation we did things a little different by changing B1, B2, B3, ...". This would distract the reader from the main point and becomes extremely disruptive from the point of view of the narrative flow. But somehow, it feels wrong to leave these details out since readers would otherwise assume we use the previous approach, or would simply not know how exactly we carried out the work.

I am wondering what are useful and effective strategies to write papers that can be read smoothly when there is a lot of fine detail involved that has not been previously published.

Answer 1

My field is biomedical so comments may or may not work for you. In our works, sometimes protocols did change along the way and occasionally I need to explain that in the paper. Hopefully these comments are general enough to be useful to you.

The primary goal is to think from the gain of the reader and maximize the gain:pain ratio. You want the ratio to be high: transferring the most to them with them going through the least amount of effort to understand your work. With that reason in mind, here are some suggestions:

1. Really, very few people reading scientific journals are interested in the step by step saga in how we reach there. I know it may come off harsh but what matters to the researchers during the development process can be drastically different from what matters to the readers. So, cast a critical look and weed out details that are not bringing any gain.

2. Minimize the "we wanted to do this, but then we ended up with that..." frequency. Try not to start every single sentence with this kind of structure because they sound trivial and never-ending. Instead, I'd suggest setting up a section called "original plan" (to hint that something was changed) and give it a good introduction. Then, you can have a section called "Modifications" to briefly but sufficiently explain major design changes.

3. One device I found very effective is a graphical schematic. You can consider a graph of the original scheme. Then in the Modification section, use the first graph as blueprint, slightly grey out the contents, and then insert modified components in 100% black. Consider indexing the changes on the graph, and then in the text you can simply explain them sequentially.

Answer 2

Separating papers into a "here's a new method" methods development paper and "here's where we apply a new method" application paper is somewhat common. Neither paper may go to as good a journal as a combined paper would, but it's an excellent choice if the audience for the two sub-parts is different.

For example, the people who care about computational modeling and the fine details about computational modeling protocols are normally quite different than the people who care about specific applications to which the methodology can be put. Therefore, if you develop a new computational method for a particular application, it's often helpful to have one paper aimed at the computational modeling people, which goes into the nitty-gritty of the protocol but perhaps only demonstrates it with toy systems, which is sent to a computational modeling-focused journal, and then have a separate paper, which may gloss over the protocol details but focuses on the real-world application, which is sent to an applications-focused journal.

Key here, though, is that you're not really splitting up the paper arbitrarily because it's too long, you're splitting it up because the focus of each sub-paper is different.

In that sense, I don't think your proposed split is ideal. Paper 3 sounds decent as your application paper, but it sounds like Papers 1&2 might really be the same methods development paper, salami sliced for convenience. That's probably why you can't find a separate story for Paper 1 - it doesn't stand alone as a methods development paper.

That's not to say you can't split up your methods development paper, you just need to do it on a topics basis, rather than an overview/details basis. For example, can your methodology be split into solving two independent sub-problems, each of which can stand alone as its own method development paper? Or perhaps there's a problem which is a simpler general case (where you can present a simple solution), and then a more-specific instance of the general problem which permits optimization or where the general case doesn't work, which can be presented as a second paper.

Finally, there might not be a good place to split the methods paper or you may decide against it. In that case, Supplemental Information (or Supporting Material) can be your friend. Write up your methods paper (e.g. Paper 1), but put the distracting details (e.g. Paper 2) into Supplemental Information. That way you can refer to the details briefly in the text, but still have a paper that's a self-coherent unit, as you expand upon it in the SI.