The Lovelace Lecture

“This lecture pays due tribute to a lot of our computing heritage,” says Alan Pollard, BCS President in full regalia with a presidential medal around his neck.

I take my seat in the conference room of The Wellcome Trust. It’s a beautiful space. One of the best things about attending events is getting to nose around other people’s offices.

Each year the Lovelace Medal is awarded to someone who has made an outstanding contribution to IT. In exchange for the medal, the winner has to give a lecture and it’s one of the most prestigious events on the IT calendar. We are gathered to listen to Dr Tony Storey from IBM, but unfortunately he isn’t here.

Ian Nussey takes the podium and explains that Tony isn’t well. He gives us a pencil sketch of the man we won’t be meeting. Tony prototyped the world’s first relational database. He has spent two decades working at IBM. He’s won lots of awards and done a ton of technical stuff with Java and MQSeries. He’s a self-taught guitarist. He breeds tortoises. He started his treatment this afternoon.

Standing in for Tony is Maurice Perks, who was made an IBM Fellow at the same time as Tony. He has a presence at the podium, as if he’s used to people listening to him. And we are listening.

“The sins of IT projects and why they can fail.” Maurice’s voice would carry without the mike.

He defines failure as not delivering the functionality on time and to budget: OTOBOS. He defines a large project as one that takes over a year, and then explains what the top issues are with IT projects:

  • They are big because they have lots of users
  • The technology changes fast
  • IT requires a diversity of skills from business analysis to chip manufacturing
  • They are very expensive and that makes them visible.

The rest of the lecture is Maurice’s top trouble spots, but not a lot about how to fix them. He’s entertaining and interesting, but I can’t help feeling like I know all this already, all these soundbites strung together.

  • Don’t assume testing is a mere formality.
  • Integration is about breaking it down but then building it back together again.
  • Some bits of projects are not under our control, like an interface to a third party.
  • Don’t manage the method.
  • And Perks’ First Law:  “Components that are not designed to fit together and form a working system only do fit together by chance.”

Maurice’s advice to tackle poor project performance is to break things down into smaller pieces, and understand the risks and changes involved. He’s an IBM Fellow, with more years on the job than I’ve been alive. He’s confident and self-assured. And right. We all know he’s said sensible stuff. But talking to people afterwards one thing is clear:  if we knew it all before, why are IT projects still failing?