WIRED:Even when the project was obviously careering into a ditch of delays, unwanted features, and unusable interfaces, no one was able to stop it
DO YOU KNOW someone who has been mentally scarred by a major software project ending in disaster? I always assumed that this was a psychological trauma that only programmers have to deal with. Certainly, it’s one of the few areas of a geek’s life that actually has psychological self-help books written about it.
My favourite remains Ed Yourdon’s Death March, which is a classic for how to personally survive such projects with your self-esteem intact.
But the more I’ve thought about it, the more I realise that the damage bad business software projects has wrought is incredibly widespread.
For instance, my sister rethought her entire career after taking part in a multinational, major coding project for a Fortune 500 car company.
It was supposed to allow employees around the world to work together on designing the next generation of automobiles, perhaps one of the more exciting aspects of that business. She loved working on such projects, and she loved the people that she’d be able to help. But the whole things was saddled with so much baggage from early designs that even when it was obviously careering into a ditch of delays, unwanted features, and unusable interfaces, no one was able to stop it.
Despite being entirely non-technical, the stress of having to deal with a project that turned into a train wreck so spectacularly that nobody ended up using the software, and man-decades of time were wasted, soured her on the entire business. She now works as a teacher.
Talking of teachers: I’ve known many educational workers who, when they’re not fighting bureaucracy, have fought well-meaning but doomed software projects to make their lives easier. I know, because I was one of those well-meaning programmers.
The educational workers would describe, gently, some problem they were having, and I would go away and code something up which, I suspect, had absolutely no connection with the problem they wanted to solved, but looked great.
It was also, I’m sure unmaintainable. The moment one part of it stopped working, the whole system was doomed to fall apart.
Looking back, I don’t think I wrecked any lives, but my software certainly never got used. If it had, maybe I would have seen more educationalists around my house with pitchforks.
Things are getting better, I think. At the very least, some experienced business leaders have got the message of decades of software disaster, and no longer assume that a bunch of consultants and a multimillion euro budget is going to guarantee success. IT departments have grown more conservative, and have been able to fight back against executive-led “improvements”, sold to them by software sales staff.
But it still happens. When someone proposes a crazy software project that you know will disrupt your work life and looks almost doomed to fail, what can you do?
Technical people are usually the most glum and pessimistic of the chances of such endeavours, and yet their survival trait is often to assume a blithe workplace optimism about the problems. Rather than face up to the consequences, they seek to bury themselves in the minutiae of the technical challenges, and hope no one blames them for the impending screw-ups.
Blinding themselves to the social side of the problem means also hiding away as much as possible from its consequences. The last thing a bunch of coders building a system that is failing to help anyone wants is to be stuck in the same room as the people it is abjectly failing. By contrast, almost everyone non-technical I know in this situation has fought back the only way they know how, by passive-aggressively sabotaging any step the technical team takes. Technical and non-technical teams end up on different sides of the same fence, refusing to co-operate because co-operation seems futile.
My guess is that what we need more of isn’t enthusiasm, or scepticism, or nihilistic fatalism. What we need more of is insurrection.
Coders and business staff being screwed over by outside sales teams, consultants, and their own executives can only survive by working together to keep all of those people off their backs.
That involves an active sabotage of the usual lines of command. Most coders in big internal projects are either conducting work on behalf of mutual bosses who are too high up to see what is being messed with, or for external consultants.
They need to turn against them both, find out who is really affected by the software they write, and work with them instead.
And if you’re in an organisation where a new IT project is about to wreak havoc, your only chance is to make direct contact with those assigned to build the bomb, and work with them to defuse it.
Removing the threat, though, doesn’t mean simply destroying the project itself.
We all know, at this point, that software can work. Sometimes, it can actually make things better. Not every device or program we use sucks.
Sometimes it can be efficient, improve how we work together, and even sometimes be beautiful. Coders hate writing those awful intranet applications and internal corporate horrorware as much as employees hate using it. If they unite at the start of a project, we can fight back against the ponderous plans of bosses and contractors.
