While not essential to the argument, it uses software development as an analogy for scientific publications. Unfortunately, that analogy isn't correct. > Just

While not essential to the argument, it uses software development as an analogy for scientific publications. Unfortunately, that analogy isn't correct. > Just as the software industry has moved from a "waterfall" process to an "agile" process—from monolithic releases shipped from warehouses of mass-produced disks to over-the-air differential updates—so must academic publishing move from its current read-only model and embrace a process as dynamic, up-to-date, and collaborative as science itself. "Agile" is one name for a long line of software processes, which includes XP, RAD, and Unified Process. Iterative development stretches back to the dawn of software engineering. In modern practice, "agile" seems used for anything which is even a touch more flexible than the strictest of waterfall. Take your process, add a standup meeting or story cards, and poof, you're agile. Nor is "agile" development tied so closely to 'over-the-air differential updates'. The development methodology has very little to do with deployment. Perhaps the easiest example is to look at the various language implementations (Python, Ruby, gcc, etc.). They don't have auto-update. So I guess the question is, are they agile? > But academic literature makes no distinction between citations merely considered significant and ones additionally considered true. What academic literature needs goes deeper than the view of citations as kudos and shout-outs. It needs what software engineers have used for decades: dependency management. > A dependency graph would tell us, at a click, which of the pillars of scientific theory are truly load-bearing. I have no idea of how to make this work. I give as an example the Kabsch algorithm algorithm for RMSD minimization of two molecular structures (see http://en.wikipedia.org/wiki/Kabsch_algorithm http://en.wikipedia.org/wiki/Kabsch_algorithm ). The original paper contained an error that sometimes resulted in a sign error. This was fixed in a subsequent paper. Most cite the first paper, because it introduced the core concepts. Some cite the first paper but actually implement the correct solution from the second paper without even realizing there was a problem, because they combined the principles with their own mathematical understanding rather than duplicating the exact steps in the paper. Still others cite both papers. How does this hypothetical dependency graph incorporate those details? That paper is a simple one, because it really is a single algorithm for a single goal. Many papers introduce multiple concepts, solutions, or observations. It can well be that one of them was wrong while the others were correct, interesting, and influential. For example, in one paper I read the authors did not include a test case because, they said, the source material was invalid. I investigated, and discovered that it was due to a transcription error by the authors of the paper, and not a problem in the source material. The addition of that one data point would have no material impact on the overall paper. But it's still wrong. How does his hypothetical dependency graph capture the multitude of disprovable points in the average paper? How does it capture what the "pillars" are? Bear in mind that there's been over 50 years of attempts to do this, so I think there's no easy answer.