The hugely gratifying response to our questionnaire last month showed
(see this month’s lead), inter alia, that readers like Oil IT Journal
when it is debunking stuff. Personally I like it even better when we
can report on others who debunk stuff for us. So just to kick off this
200th editorial, a couple of recent third party debunks...
You have probably heard many speakers exhort you to ‘pick the low
hanging fruit,’ with the implication that this will lead to the best
allocation of resources. Well our first debunker, McLaren Software’s
Tim Fleet said earlier this year1, ‘don’t pick
the low hanging fruit.’
Doing so makes for projects that, while easy to implement, are unlikely
to represent the real world. Shell’s Johan Stockmann should get a
debunker’s award for his two
contributions made at the SMi E&P data conference last month2.
Stockmann urges us to ‘forget the single version of truth’ because there
isn’t one and also to avoid ‘buy not build’ blindness. In other words
there is plenty of stuff that is best done in-house.
In the February 4th issue of the Financial Times Martin Wolf was
inspired by a new book3 on the ‘next big thing’
to hit us all, the
arrival of smart machines that will eat (more of) our jobs. Not having
read the book I will refrain from comment on this theme. But one of
Wolf’s asides got me thinking along lines that have previously
landed me in trouble. Which is a good reason to revisit the topic. Wolf
cited Robert Solow who, back in 1987, quipped that, ‘we see information
technology everywhere except in the productivity statistics.’ Wolf
reports trends in output per hour in the US as ‘quite mediocre.’ I
would like to suggest why this might be so.
A remark attributed to IBM founder Thomas Watson put the worldwide market for computers at ‘maybe five.’ While this is both apocryphal4 and wrong it reflects what was at the time (1943!) a possible trajectory for the fledgling industry. The following decades saw a market of more than five. But the paradigm of big machines doing a lot of stuff, increasing productivity and destroying a clerical jobs largely continued.
Early computers were also designed to be programmed by subject matter experts. They were programmed in languages that were tuned to the task in hand. Cobol for business use and Fortran for scientists and engineers. This situation offered an effective way to harness the power of computers in service of the business—a highly efficient paradigm that brought the early productivity gains. Both languages by the way are still in widespread use5.
Then came the personal computer which threw a spanner in the works, leading to the situation we have today of a huge IT industry that is dependent on having a large number of ‘bums on seats,’ all using software that is tuned individual use. Practically all upstream software outside of seismic processing falls into the same ‘single user’ category. In fact, although big computers are commonplace, their use cases are somewhat forced. Running multiple simulations for Monte Carlo analysis is OK, but what about running the business?
Across industry, in finance, engineering and just about everywhere else, the worst offending (and most ‘personally productive’) application is of course, Excel. The ubiquitous spreadsheet allows the individual subject matter expert to develop ‘solutions’ to just about anything. But their scope is limited to the user’s own desktop. Gathering the results from such dispersed activity is hugely problematic in the enterprise.
If we now turn to the tools of the trade, the old domain specific languages, these get short shrift from the programming community. Their crime? They are just old and worn out. Vendors have replaced them with a plethora of languages that suit their own purposes. These may include worthy aims (although not necessarily yours), like working well with the web. Some aims are less worthy like vendor lock in. Subject matter experts wanting to develop solutions to business problems are faced with near insurmountable barriers of programming complexity and may have to throw in the towel and abandon development to ‘IT.’
You may think this is all a bit cranky and it probably is. But bear with me and try an economic analysis of the situation—in other words, ‘follow the money.’ Imagine that somehow, a substantial productivity gain, as seen in the early days, was achieved today. What would be the effect of this on the likes of Intel, Microsoft and Apple? It would be disastrous! Less bums on seats, less chips, software licenses and hardware sold! This is definitely not how these players see their future. Much marketing effort is directed at avoiding any real rationalization, pitching instead, tools for oxymoronic ‘personal productivity.’
In the 1870s, Mr. Remington designed his typewriter keyboard to decrease productivity, with a sub-optimal placing of the keys to slow down typing and avoid jams. In my considered and conspiratorial opinion, Microsoft’s ‘ribbon’ was designed with similar intent—to slow things down and reduce productivity. I sincerely hope that the ribbon will not be with us for as long as the qwerty keyboard. If it is though, what a triumph for futzing!
I realize now that our 200th edition online questionnaire may have disenfranchised some of our print copy readers. If you would like to contribute to the debate, the questionnaire will remain up for another month and you can email us at info@oilit.com. Hey, you can even write us a letter and send it to The Data Room, 7 Rue des Verrieres, 92310 Sevres, France.
1 Oil ITJ January 2014.
2 See page 6 of this issue.
3 The Second Machine Age, Erik Brynjolfsson and Andrew McAfee.
4 Wikipedia.
5 ibid.
© Oil IT Journal - all rights reserved.