cloud – Adam Bager

I attended a conference recently where, by chance, I met someone who’s using the expense management system that I design – expense@work. It’s always a little alarming when you meet a real user since you must expect them to be honest, and there are no better judges of what you’ve done. This one was direct:

‘I hate it,’ he said, with the kind of mock fury that told me that he knew he was exaggerating and didn’t really want me to go away and kill myself.

‘Why?’ I asked.

‘Well, it’s so out of date. I can’t attach images to my expense claims, and I can’t use it on a mobile device,’ and so on.

‘But you can,’ I said. ‘We’ve had those features for years.’

‘Then why haven’t we got them?’

‘I don’t know.’

It’s so frustrating, but this happens time and time again. And not only with our own software. We also sell and implement a financial system, SunSystems, and again, we often have to deal with users who want features that we have, but who aren’t getting them.

This is actually a widespread problem in system implementation and the end result seems to be unnecessary reputational damage for the software author.

Why does it happen and how can it be avoided?

It happens because system implementation is a lengthy, expensive and risky business and end users don’t often determine what’s on the list of features that they’re going to get. Sponsors and project managers on the client’s side have a highly controlled, and usually narrow, list of objectives, and their criteria of success won’t usually include the implementation of features that are merely ‘nice to have’ but not necessary.

That’s why ‘nice features’ don’t make the list during an initial implementation, but it doesn’t explain why nice new features don’t get implemented later as soon as they become available.

The problem is that once a system is implemented, the policy becomes ‘if it ain’t broke, don’t fix it’, so new versions with ever more up-to-date features, don’t get implemented either. And this is eminently sensible, because upgrades take time, often go wrong (for a while at least), and cost money. Upgrade projects are sometimes almost as large, expensive and risky as initial implementation projects, even if the software automates many aspects of the upgrade (such as updates to the database).

Software authors want their software to be liked by their end users. End users want ‘nice’ features. The obstacle lies between the two, in the conservatism of the client’s project managers and IT department.

Sadly, I can’t see what’s wrong with this. ‘Conservatism’ is a very sensible policy with business systems. The tragedy is that result is frustration on one side and unhappiness on the other. is there anything we can do about it?

I ask this question without knowing the answer. I wish I could find a way to deliver new features in software without risk or disturbance. But this is difficult. Business software isn’t like a desktop productivity tool. The problem is that what you do in one corner of the system can have unintended consequences in another corner. And when a system is implemented for a client it’s often integrated with lots of other systems, so a change in one corner of our part of the whole, can disturb a corner in another part that isn’t within our control, as authors of just one part, at all.

To some extent this problem is solved in ‘cloud’ or ‘hosted’ solutions, because authors then control the version that an end-user uses, and can introduce and publicise new features without obstruction from intervening project managers.

But ‘cloud’ and ‘hosted’ solutions aren’t always suitable when it comes to complex business software, especially when the software must be integrated with a client’s own systems. When there is deep integration, conservatism rules, and must do so.

And yet, it’s so frustrating to meet end-users and to have to repeat time and time again,’But our software CAN DO THAT!’

Any ideas?

I am grateful to my brother for forwarding to me this particular piece of nonsense. The text comes from publicity material for an exhibition in Porto, Portugal. It’s an example of the pretentious and meaningless rubbish that pretentious and intellectually vacuous museum curators and art critics will write, if asked or paid. It makes no sense at all, as far as I can see, and I don’t see how it could possibly be of use to a visitor, or for that matter, attract a single visitor to the exhibition.

Since the second half of the 20th century, we have lived under the shadow of two clouds: the mushroom cloud of the atomic bomb, and now the “cloud” of information networks. How did the metaphor of post-war paranoia become the utopian metaphor for today’s interconnected world? Under the Clouds confronts the interrelated effects and affects of these two clouds on life and work, leisure and love, and on images, bodies, and minds. If the mushroom cloud represented the potential annihilation of human civilization, the “cloud” is the diaphanous representation of the network-driven, information-saturated conditions in which we increasingly live. We are assailed with the effects and affects of the cloud; data overwhelms us with needs, demands, and sensations. Information floating in the cloud—where data is now increasingly stored and controlled—replaces the invisible threat of radiation, moving through apparently unseen yet pervasive ways. The singular image of the cloud, unseen yet floating above us, stands for everything from the abstractions of the financial system, to the increasingly mediated character of our social relationships, the role of algorithms, and the affects of liking and sharing. In these ineffable clouds lies the phantasmagorical nature of our contemporary sublime.

The information technologies of the nuclear era have now evolved to fit in the palm of our hand; we no longer merely look at images, we now touch, scroll, pinch, and drag them. Where is the border between the self and its data shadow, between information, memory, and knowledge? The biological, economic, and political effects of living under the clouds have taken the form of new relations between data and material; screens, images, and things; and the changing nature of sex and work. As earlier forms of technologically inflected art sought to mitigate the effects of rapid change—both on perception and society—many of today’s artistic practices confront the myriad interfaces and decentralized networks that continue to shape and transform daily life, forming new evolving connections between bits and atoms.

This must have been written by Joao Ribas, curator at the Serralves Museum. He’s a prize-winning curator. Such prizes, no surprise, are awarded by curators to each other.