I'm gonna disagree with this. I worked in non-academic research setting, quant trading, where you have a big data set and want to show that some trading strateg

I'm gonna disagree with this. I worked in non-academic research setting, quant trading, where you have a big data set and want to show that some trading strategy is useful. It's kinda like research in the sense that you're discovering things from doing a lot of data-fu. But you're not in the business of sharing the results with peers at other institutions. What you end up with is endless versions, stemming from endless "what-ifs". The argument that you won't go back is wrong. Often it's not that you want to reset everything to a specific version, it's that you forgot what the assumptions were at a certain time. You want to know why you were doing what you were doing as much as how you implemented it. Often it's only the comments you need. What you also need is commit hooks to test that your assumptions continue to hold. Your dataset contained 1000 stocks? Boom, something changed and now for whatever reason it went down to 10. Now you know, and you didn't waste a bunch of time picking apart everything until you found it. Or mundane things like whether some data file has been downloaded, or whether the OS has enough free space to do the analysis. The more you have of this, the more you benefit in the long run. The "git is hard" argument is a big red flag for me. Git is one of those things where I also had loads of weird issues when I was new to it. It's worth reading some books about how it works, and trying a few apps that help with it. However, I also get a strong "I just need it to work" vibe from this piece. It's unfortunate, but I think a couple of weeks worth of reading on how git works is well worth it. I'm bu no means a git guru, but I have read books about it, and I mostly stick to the simple commands. The thing about the graphs seems a bit strange to me. There's libs for making graphs that you can customize to your liking. Once the graph (or any binary blob) is made you can hash it and check it in a unit test. I've done the same with video outputs, it tells me if something changed. Dropbox seems like the cloud version of folder4/version8_final_last_ultimate_2.xls to me. I wouldn't touch it, I would do things in script. > These rationales don’t really apply, though, to code that people will write for analyzing data for a particular project. In our lab, and I suspect most others, this code is typically written by one or two people, and if two, they’re typically working in very close contact. This part is problematic. What are you gonna do when one of those people leaves the team? What's different about analyzing data? If anything, analyzing data for a project ought to be totally reproducible, since there's no moving parts. If you need a random seed, save that as well. When you move on, someone else should be able to clone your repo, and after slogging through all the test cases they should get the same numbers as you.