What’s wrong with economic models?

Advertisement

As linked this morning, Dr Steve Keen is getting a bit of attention from Paul Krugman after he wrote a Primer article on Minsky in which he called out Krugman, among other neo-classical economists. This was also covered by Philip Pilkington over at Naked Capitalism.

I’m not going to address the discussion directly, but essentially, Dr Keen is making a point that Neo-Classical economists ignore private sector debt, to their own demise. Until quite recently however, Dr Keen himself also appeared to ignore vertical transactions. That is, transactions between a fiat issuing state and its private sector.

Where I have time for Dr Keen’s analysis is his study of debt dynamics, which has been very valuable, I do think he made some key mistakes in his projections for Australian private sector credit. When the GFC hit Australia, he didn’t appear to understand the ability of counter-cyclic monetary and fiscal policy to support both private sector wealth and a re-ignition of private sector credit demand.

Advertisement

Since that time it appears Dr Keen has ventured towards the realm of Modern Monetary Theory, possibly under the guidance of Randall Wray and/or Bill Mitchell, two major advocates of MMT. I am obviously speculating here, as I don’t follow him that closely, but from what I have seen of him over the last few years that is certainly my impression. I am obviously happy to be corrected if I have got any of this wrong.

That however isn’t what I want to talk about in this post.

What this exchange actually got me thinking about was how trapped economists are in their models, some of which were built on economic theory that pre-dates modern factors such as fiat and floating currencies. The fact that economists use models may not seem to be a big issue so let me try to give you an analogy from a non-economic area to explain why I consider this to be such a problem.

Advertisement

Although I can’t claim to be an expert in this area, the realm of computing has a good analogy with regard to Object Relationship Mapping (ORM) . For those of you who aren’t information technology professionals the basic idea of these tools is that they allow software developers to represent data in the form of objects, such as a person, or house etc, and by doing so they abstract away how exactly those objects are going to be stored in underlying database.

These tools are extremely useful because they allow software developers, who may not have particular skills in the area of database technologies, to very quickly build models of the data they wish store as part of their software. These ORMs then go about automatically generating all of the necessary software components to do the actual work of storing the data.

This allows software developers to build an abstraction layer between the domain they understand, software, and the domain they may not, databases. This process works very, and is a very common software engineering practice these days because, in most cases, it significantly reduces the time it takes to build a piece of software.

Advertisement

There are however a couple of problems with using ORMs and a major one stems from the fact that the software developer doesn’t have to understand how the underlying database system actually works. He/She can simply add data through their model (an abstraction) and the data is persisted in the database. That is, for many software developers, especially younger ones, the database system is a ‘black box’.

Because the software developer doesn’t actually have functional knowledge of how the database system stores information the software tends to works very well until a certain limit is reached. At this point, let’s say around 1 million records in the database , the system starts to perform outside the boundaries of how it is ‘expected to’. And now we have a serious problem. The software developer doesn’t actually understand how the underlying storage mechanism works because he/she is viewing the system through a model that is an abstraction that hides away the important complexities of how the system actually functions.

It is usually at this point that the software developer goes and finds the database administrator. This, in many cases, is the old guy with the beard who sits in some dark corner of the office grumbling about better days when computers were simple and there were far less idiots to deal with. The database administrator starts shouting at the developer that his software is creating massive amounts of inefficient code that is causing the database queries to take an excessive amount of time. If he/she only bothered to learn about the important complexities of the database system itself, that is, how the system actually worked instead of modelling it, they never would have designed the system in a way that would inevitably lead to failure.

Advertisement

After a couple of hours work the Database administrator returns with a new version of database query which, although produces the same results, takes a 50th of the time to execute. The software developer puts this “special code” into their model and goes back to viewing the database as a ‘black box’.

So now you may understand my concern. Models are wonderful things because they allow you to simplify complexity, but in doing so they also abstract away things that are fundamentally important to understand. That is, they work well right up until they don’t.

This is why, just like computer programmers, I believe it is fundamentally important that economists learn the functional mechanics of the economy before attempting to provide some abstractions of how it works.

Advertisement