Working from home—actually from the garage, in the time-honored tradition of the IT start-up—I observe folks heading off to go to work on the public transport system with quiet satisfaction. Not having to ‘go to work’ saves me two hours of commuting time—and an untold amount of hassle. Of course, working from home means other benefits, like not having to shave, get your hair cut and wear a suit and so on (rest assured, I do still wash occasionally).
Amstrad
Reflecting on haircuts and going downtown to work reminded me of one of the most successful IT developments I have ever seen. This was probably about twenty years ago, just after the IBM PC had established itself as the ‘standard,’ but before it had driven off all the competition. My downtown hairdresser used to have an Amstrad something or other and I would josh him about this, asking when he was going to get a PC with one of these newfangled hard disk thingummies.
Bespoke
He really wasn’t very interested. Like many folks with a ‘life,’ he didn’t want his business dominated by computers. The bespoke tool that he used (and which probably cost ten times what he’d paid for the computer) had a couple of compelling virtues; it did the job it was designed for and it was quite easy to use. Moreover, because his business did not change a lot from year to year, he really didn’t expect new versions, upgrades, bells, whistles and so on.
IT nirvana
Functionally, this was IT nirvana. Let’s deconstruct the process a bit. The hairdresser has a need for some basic record keeping, check printing and saving data on a floppy for the monthly visit from the accountant. The IT folks come in, write the software, it works and they get paid and then go away. Simple isn’t it? Except that to anyone in IT there are some glaring holes in this story: where is the maintenance contract? Where are the upgrades? Who fixes the bugs? In other words, where are our jobs?
Labor market
In terms of the labor market, this development project can be analyzed thus. Before project: zero jobs. Duration of project: one or more jobs. After project: zero jobs. This is what I call the plumber’s business model. You call them, they come along and fix what’s wrong (I know that it ridiculous to imagine that a plumber will even answer the phone—but that is another issue). Then they go away.
Clipper?
Of course my ex-hairdresser no longer has an Amstrad. When the machine fell apart physically, Amstrad was no longer building these machines. He was forced to get in line and now has a PC (although a Clipper-based machine would have been more appropriate), an off-the-shelf Hairdresser’s Business Management Suite, along with annual maintenance, upgrades, new bugs and old bug fixes. Why? Because this is the way of the IT world. IT prides itself in ‘rationalizing’ and ‘downsizing’ other people’s jobs. But when it comes to downsizing its own activity, the IT world actually works in reverse, generating activity for itself, oftentimes with little benefit to the user.
Revolution
IT’s early days (say the past 20 years or so) have seen a successful fight against nature to preserve or create new jobs. While good IT design should expose increasingly simple interfaces to users (and I am really talking about programmers here), the ‘success’ of IT in job preservation has been to offer staggering complexity, changing paradigms—ensuring an ongoing cultural revolution, and employment for all. Instead of developing a tool—and then quietly retiring, developers manage to milk clients for 20% maintenance fixing their own bugs and offering meaningless enhancements such as re-engineered tools fitting the latest IT paradigm. Even though the end user couldn’t give a damn whether the thing runs on Linux, Windows XP, is object oriented, ‘engineered for re-use’ (hilarious, that one), or standards compliant.
Downsizing
The downsizing of Shell’s IT department could be interpreted as reflecting a (slow) structural change from an industry where one program begets another, where a few months of development leads to years of maintenance. Standardized applications and infrastructure are part of the solution. But what of the other side of the coin—the offshoring exercise?
Offshoring
If outsourcing is in part a way of redressing the balance and ensuring that IT projects don’t turn into jobs for life, offshoring is a quite different dynamic. One major E&P software vendor told Oil IT Journal of their experience of a major offshoring exercise which has been running for the last four years. This involves the wholesale offshoring of a major upstream software tool. It has been a mixed success, in part because the offshoring partner, as an IT professional, is extremely compliance-oriented.
No quick fix
What’s wrong with that? Nothing, except it is harder to get your ideas translated into code if you have to fill in reams of specifications, rather than go down the hall and chat to the developer. It gets hard to implement a ‘quick fix’. Offshore software houses also may need a education in the strange ways of the upstream industry. All of which means that the hoped-for cost savings have not materialized. The offshoring exercise has generated mixed feelings. But what has changed is the ease with which a project can be abandoned without having an army of developers to re-deploy. Which is, in a way, a return to the plumber’s business model—but what a circuitous route!
© Oil IT Journal - all rights reserved.