Statistical practice

If you are used to splitting the quantitative analysis work between scientists and computer programmers, you are very likely running a SAS shop. You do have the right idea that the science of statistics and the practice of statistical programming are quite distinct and different people tend to be better at one or the other. But the practice of splitting the actual work among scientists and programmers is not best. It’s just common.

I think that companies doing things this way are stuck in a trend, not setting one, though that is not as bad as it sounds. Their most important asset may well be their people, but surely the next most valuable thing they own is a pile of software essentially written a decade ago and now running on autopilot.

However, that sort of asset base is a mixed blessing. It works great in production and not so well in prototyping. If you compete on the latter -- as you must if you innovate -- you will find that your most effective people are scientists who know how to program. In prototyping, PhD’s equipped with the right software will get the job done faster, better than PhD’s teamed up with programmers.

If your team consists of PhD's who know how to program, chances are you're running a Stata shop. In that case, you might still appreciate competent outside help, because experienced subcontractors can give you a decisive advantage in two main ways. One is their current portfolio of tried and true programming practices; some of them may translate to your business without any learning curve at all. The other is the increased productivity that comes with experience, which enables them to adopt your own carefully developed practices over a much shorter time than a new hire could.

I have bet the mortgage on the Eno River Analytics headquarters on that. One year on, it still looks like a good idea.