Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: adoption practices


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   st: RE: adoption practices
Date   Mon, 25 Oct 2004 22:00:33 +0100

We agree; my comments were aimed at different arguments, 
and thus different people. 

Nick 
n.j.cox@durham.ac.uk 

Kit Baum
 
> Nick wrote in response to my posting
> 
> I'd agree with Kit in broad terms, but invert that order.
> 
> It can be pretty obvious to StataCorp and many others that
> (1) is true of a package, and apparent that (2) is true,
> but (3), expanded realistically, is the crunch.
> 
> Any idea that (1) and (2) qualify a user-written program
> for adoption by StataCorp misses out what's involved:
> 
> (a) scrutiny of code
> (b) scrutiny of help file
> (c) writing dialog if not done
> (d) writing and running test scripts
> (e) writing manual entry
> (f) tech support
> 
> 
> I did not intend to suggest in any way that (1) and (2) taken 
> together 
> are by any means sufficient; for an economist, (3) on my list---the 
> provision of tech support (including maintenance, enhancements, 
> documentation rewrites, etc.) is a MUCH bigger commitment, since its 
> cost is the discounted present value of doing that work (and 
> competently answering the user questions about the routine) 
> from time = 
> t to +\infty.  Even at a high discount rate, that is a large number, 
> and if it is not an affordable sum, Bill G. the economist will not be 
> willing to shell it out.
> 
> To say nothing of the costs of Nick's item #4 above: anything 
> added to 
> Stata has to "play nicely" with everything that is already there, and 
> that requires (using Stata's published standards; see Bill G.'s SJ 
> article on software certification) a LOT of testing (and retesting, 
> every time a single new feature or bug fix is made! On every platform 
> supporting Stata!) Yes, if I was on the StataCorp payroll, I 
> would not 
> be real keen on adoption, as much as I would want the package to do 
> everything for everybody.
> 
> StataCorp have, IMHO, taken an alternative strategy (to creating a 
> bloated behemoth with manuals no one can lift): they have made it 
> trivial for you, me, Nick, and everyone else to set up our favorite 
> procedures and distribute them costlessly via SSC, user 
> sites, SJ, etc. 
> Do I have the same confidence that any user code (including 
> my own) is 
> as bulletproof as what comes out in 'update ado'? Of course not; the 
> quality of the offfcial updates is what I'm paying good money 
> for when 
> I buy a new version of Stata (and those who are not eager to update 
> ought to think about that). But just as in literature, some 
> authors are 
> better craftsmen/women than others...
> 
> Kit Baum, Boston College Economics
> http://ideas.repec.org/e/pba1.html

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index