My personal triggers for packaging are:
- I find I'm again using some code that I once wrote for another data analysis project.
- I think I'll need the method I just wrote again.
A colleague asks me for code. A substantial part of the code I write is at least as much on request of colleagues (who use R but do not program that much themselves) as for myself.
I use the formal requirements of a package (documentation) to "force" me clean up and document my code.
I agree with @JohnRos that there is quite a difference between writing a package and publishing the package.
I usually package early, but then make the package only "semipublic". That is, it may be available on an internal server (or on r-forge), so my colleagues
can access the package. But I publish to CRAN only after the package has been used for months or even a few years by close colleagues. This doesn't bring up all bugs according to @Nick Cox's point #3, but a fair amount of them.
The versions of the package (I put the date after the dash in the version number) make it easy to fix things ("to do this and that, make sure you intall at least last week's version")
According to my working contract, my employer has the last word on the decision whether and how a package can be published to the outside world.
The thing where I do not yet have a good strategy for packaging is data.
Comments to your list of reasons:
- the non-existence of other packages in the same sub-field ;
Not finding a package that does what I need for me triggers writing the code, but it doesn't have to do with the decision whether to package or not.
- the need for exchanging with other researchers and allowing reproducibility of experiments ;
Definitively. Possibly already the need to share between several computers I use.
And amongst the points that could lead to a contrary decision :
- part of the methods used already present in some other packages;
you could import those methods into your package/code: this is a point against writing such code, but has only indirectly to do with packaging.
- number of new functions not sufficient to justify to create a new independent package.
For me, there is no minimum number of functions to start a package. In my experience packages tend to grow "automatically". On the contrary, after I've found myself a few times branching off a new package out of another (because e.g. some helper functions in the end turned out to be thematically different and useful in other situations, too), I'm now rather creating new packages immediately.
Also, if you didn't write documentation and tests, this can be a prohibitive amount of work when a "sufficient" number of functions for creating a package did accumulate.
(If you do write them immediately, then the additional effort of putting it into a package is negligible once you know the workflow).