April 27, 2007
I’m going to write about software productivity and how it might impact software engineering, including programming languages. However, I first need to understand productivity by skimming the work in economics. Strangely, measuring productivity is a crude pseudoscience. [Read this mumbo-jumbo (pdf) about productivity.] To measure national improvements in productivity, they simply divide outputs by inputs. It once costs $1 to produce a $3 widget, now it costs $.75 to produce that widget: that’s a 33% improvement (3/1 -> 3/.75). However, if they simply raised the price to $4, that’s also a 33% improvement. But is that a productivity improvement? Even now, productivity growth has slowed from 3% (’95-’04) to 1.5% lately. But economists have to guess as to the cause. If the economy loses steam and revenue falls, but a company hasn’t reduced their workforce, then (lower output) / (same workforce) = lower productivity. Another problem is that companies produce better products (i.e. faster processors) at the same price. Is that a productivity improvement? Economists argue about this all the time. Basically, measuring productivity is imprecise and involves lots of guessing. So measuring software productivity will likely be equally tough.