We may have to think of 'investigative routines' at three distinct level.

At the bottom level, there is the intellectual content of such a routine as it might be executed 'by hand', whether it is a simple lookup, a complex look-up, a sort, an ANOVA, Naive Bayesian, cluster analysis statistic or whatever.

Whatever else we do, we must describe this routine, what it does, how it works, why it is worth doing, given enough time.

At the second level, there is the conversion of this routine into a digital algorithm done by people who know what they are doing and are good at speeding up algorithms in this way or that way.

At the third level, there is an interface that mediates thei competence to people who don't have it.

Now I have a very strong conviction that whatever is done at the interface level has first to be described at the bottom level as a chain of substantive operations. If you cannot describe in plain language why you want to do X, what it is, and why it is worth doing, it is not worth spending months of programmer's time converting X into algorithms that programmers can handle, or interfaces that make it possible for computer illiterates like me to execute those algorithms.

So going back to the 'pencil and paper' account of what X is, how it works, and why it is worth doing, has to be the first thing. And if you cannot give an account of X in those terms, it does not matter whether you wrap different X's up in a unified application or create boutique applications, because quite literally you will not know what you are doing.

This is, I think, the properly 'analytic' approach to Analytics. I know next to nothing about programming--it is a foreign language to me. But I once met a computer scientist from IIT who said that in teaching it was his regular procedure to ask his students "Have you done the English? "

I don't think we've done the English, and that's what we've got to do first.

When I say this I don't mean that the programmers don't understand what they are doing. Far from it. But I mean that we have not had a conversation "in English" between the programmers and the 'users', who are typically non-programmers about what substantive procedures are available to the users, what mappings exist between them, and why one would want to use them. And until there is reasonable clarity about those procedures and their mappings to user wants and user needs, it is pointless to talk about the architecture of applications or the shape of interfaces.