时间过得实在是太快了，还是有必要记录一下2020的一次吃瓜经历，我只吃瓜，什么都不知道。

简而言之，一个大型Longitudinal的项目已经采集了10000+的fMRI数据，一批paper分析已完成坐等投稿，第二波的数据采集已经接近尾声。此时，大神的组甩出一篇paper罗列出来某个任务的实验设计的诸多问题，那意思就是这个任务的数据废了。

这就是今年5月发生在ABCD的SST任务上的事情。Russ发一个Email给ABCD的PI，并附上paper，象征性地问下你们有没有什么建议，没有的话我们下周就上传preprint啦。

文章指出了SST任务的八个问题，并且建议在以后的数据采集中对任务做出调整。btw,这篇文章投的是elife。当然几天时间是不可能做出response的，所有人都措手不及。

We present eight issues, show their effect on the existing ABCD data, suggest prospective solutions to the study organizers including task changes for future data collection, and suggest retrospective solutions for data users who wish to make the most of the existing data.

https://www.biorxiv.org/content/10.1101/2020.05.08.084707v1

瓜吃到这里，大家可能感觉SST任务真的要凉凉，10000+的数据都废了---来自大神的响指

负责SST任务的组也只能想办法对文章中所提出的问题逐条进行回复，对数据进行重新分析。可以想象，他们整个月的工作状态都是这样的

Russ组的文章当然必须是要附上code的，而且我估计这代码至少得检查10遍以上才能release，因为你在用你的数据分析告诉别人实验设计废了，1万多人的数据废了。然而！在重新分析数据的过程中，ABCD组的人发现Russ组文章中提出的critical issue，源自于他们代码中的一个bug！！！

随后，ABCD的组写paper给出respose，表示实验设计问题确实值得商榷[其实没什么实验设计是完美的]，但是说数据用不了是基于你们错误的分析和代码，我们不同意。

We note that there were errors in the analyses conducted by Bissett et al. that inflated their estimates of race model violations in ABCD, that they did not apply any performance-based exclusions to the data they analyzed, that a number of the errors that they flagged were already identified and corrected in the ABCD annual data releases

https://www.biorxiv.org/content/10.1101/2020.07.27.223057v1

...We stress that the ABCD data are fully available to the scientific community who are empowered to apply whatever inclusion and exclusion criteria they deem appropriate for their analyses and we conclude that the ABCD Stop task yields valuable data that researchers can use to...

https://www.biorxiv.org/content/10.1101/2020.07.27.223057v1

Russ组也修改了preprint的文章，由cautionary note改为讨论design issues and solutions。

并且发了一篇名为Coding error postmortem的blog，强调了代码正确的重要性。

blog链接：http://reproducibility.stanford.edu/coding-error-postmortem/

一个什么样的bug，让斯坦福的研究者都翻车了？一个非常tricky的bug，如果不是其他人重新分析数据，自己是根本检查不出来的。简而言之，在做indexing的时候is not null: notnull()和not is null:~isnull()对结果会有不一样的影响。Russ并不是分析数据的人，这次就跟着一起翻车了。听说在和ABCD组开zoom讨论该事时候，Russ全程面无表情。

此事的影响应该是比较深远的，因为前两天还看到~

某人：组会最重要的事情是什么？

Russ: 检查代码

吃瓜结束

—END—

Opinion

代码中有的bug可能非常明显，它会直接导致代码不运行，或者是结果看起来明显不对。但是有一些超级tricky的bug，代码完美运行，结果看起来好像也没问题，这样的bug可能自己检查100遍也无法检查出来。Russ组的人都是斯坦福的，算是经验人士了，同样出了错。

我曾经历过同样tricky的bug，在matlab做逻辑判断时，如果不先去掉NaN的话，会对结果有影响。当时需要对被试根据某条件进行分组，同组的博后已经进行了分组，并且用在了她的数据上。我在她的代码里发现了此bug，意味着她之前的分组是错的，直接导致她的分析全部重做。还比如在R读取文件的时候，不注意数据类型（特别是factor）非常容易造成一些tricky的事情。类似tricky的bug比比皆是，细思极恐的是如果这些tricky的bug没有被研究者自己发现，文章发表了更不会有人发现，那么同样的结果能重复出来的可能性有多少？

回顾过去一段时间的科研经历，只要拿到组里别人的代码，或多或少都会有bug，也影响了自己的数据分析。之后的一段时间，拿到别人的某些secondary结果的时候，仿佛有种声音在回响：千万不要给我看你的代码，我只想假设你给我的全部是对的。

其实并不能指责那些写错代码的人，因为只要有人参与的工作都是会出错的，即使再有经验的程序员也会犯错。我们最常用的SPM/FSL/ANIF同样在不断的完善修复各种bug。对于一个可重复性普遍较低的领域，似乎犯点错，有点bug也无所谓，毕竟你又不是在造火箭。结果无法重复我们也可以有一百种解释。对于代码中的错误和结果可重复性低的问题，也许可以保持开放的态度，因为它们本身就是科研的一部分，科学进步总是需要很多这样的back and forth。但是我想说的是作为一名研究者，有必要对分析的准确性和结果可重复性有所追求。尽可能的了解和掌握分析中的每一个步骤，这样可以在研究者的水平上减少错误发生的概率。希望每一个严肃认真可爱有追求的研究者都不要把研究做成为了发文章而发文章的样子。