Saturday, January 27, 2007

Low level failure

The last couple of weeks - if not months - have been depressing. I've been hearing far too many stories about IT failures. Not the kind of failures that bring everything crashing down, rather the kind of failures which stop people from being productive and keep people working far harder than they need to on projects that will not live up to their potential benefit.

These are what I call Low Level Failures. Things keep working but they make people's lives miserable and cost us money.

At the risk of depressing you too here's what I've been hearing:

  • A major international bank that hires new developers and leaves them for two weeks without a PC. No e-mail, no intranet access, no tool to work with. Pure waste.
  • A major international ISP which is developing some new software in-house. The team leader has been complaining about internal customers who won't come and look at the software his team are developing. Now he's found out that the company managers want the users kept away from the software. What chance have they of delivering the right thing?
  • Yet another major international bank (there are a lot of them in London) where the project manager is preventing the team doing the right thing. The code is a mess too but she doesn't want them taking any risks. The project manager knows that if the developers leave the project is lost. What she doesn't know is that the developers see her as the problem and if it wasn't for one of them taking the lead nothing would happen. And if it wasn't for this one developer encouraging the others they would have gone by now. Somebody need to help her.
  • An investment house in the City were the internal customers who will use a new IT system don't think it important enough to turn up to meetings about the new system. Why bother developing it then?
  • Another international bank were the project is a mess. The manager in charge got drunk one night and confessed he knows they are in trouble but doesn't know what to do. Good he knows there is a problem but shouldn't he ask for help when he is sober too?
  • One of the banks mentioned above work to such internal procedures that there is nothing for the developers to do. I'm coming to the conclusion that the reason companies have internal procedure and process standards is not so much to make sure work gets done but to insure that people can't do too much damage. Won't it be cheaper to just not hire them?
  • An information supplier that decided to launch a new project. Hired an offshore development team and hired people in London for the project then had second thoughts. People started work on the project only to be told there was nothing for them to do and then get laid off. Shouldn't they have thought this through a bit more?
  • One of the banks already mentioned have a lengthy interviewing process to ensure they get good people. But it hasn't stopped them giving a job to one of the worst developers I have ever met. This person will hold the team back, they will make more work for their colleagues. Anything they do create will be a nightmare to maintain. I can only imagine they were hired to fill head count or because the person doing the interview was incompetent. Fortunately the bank procedures will probably stop them doing any damage.

Thing is, although I've heard all these stories in the last few months they aren't really new. Back in 1998 I worked for a company in the City were it took two weeks to get me a PC. When they did it was massively under powered. The support department had better PC in stock but held them in reserve in case another broke.

My point is not that failures happen in IT but that we live with so many low level failure every day. This failure saps our energy, our enthusiasm, it makes work dull and boring. In each case the situation can continue because it doesn't cause anything to really break. No crunch moment occurs. Things are just generally bad.

These examples are mostly taken from the financial markets. There are two explanations for that. The obvious one: I live in London and talk to people who work in the financial sector but I'm sure low level failures happen everywhere.

Second, the financial markets are booming just now, banks are throwing money at projects. Consequently it is easy for a project to burn money without showing a return. And because there are so many projects there is a shortage of developers so the really bad ones get hired. Not only do they get hired but they make things worse.

There is a third explanation which is quite scary but may contain an element of truth. The people I know in IT are in general good. Perhaps they are not just good but are outstandingly good. The things we see as problems are what others see as normal. Could it be that outside of my bubble the rest of the world is used to massively inferior service and IT? I hope I am wrong here.

Its easy to say "Huh, what do I care?" but actually these companies are spending your money. One of the banks not named above may be home to your cheque account, your pension, your savings. You may be a customer of that ISP, or your pension might contain their stocks. Their waste hits you.

Am I the only one to see this? Can't other people see these problems? What are the managers at these companies doing?

It is a double loss: the people on these project have a miserable time and we all lose money.

What now?

One, I feel better having shared the idea of low level failure with you. I will sleep better tonight having got that off my chest.

Two, there is a link between my last post about agile and these projects. Some of these projects were agile but not all of them. I will return to this subject soon.

1 comment:

  1. This reminds me so much of the book I oft-quote called "77 Sure-Fire Ways to Kill as Software Project". They're all in this book.

    I think you need to go back and re-read Crash: Learning from the World's Worst Computer Disasters by Tony Collins and David Bicknell to realise that this has been going on for years :-)

    -- Alistair

    ReplyDelete

Note: only a member of this blog may post a comment.