Software Projects: How to Make an Absolute Mess of Them

When interviewing, there is one question I always put to the hapless chump in front of me. Fixing him with a beady eye, I adopt my most intimidating demeanour and ask, “Can you describe a situation in your working life where you failed ?” Thinking of my own career, I expect to be regaled with stirring tales of technological woe, littered with wild optimism, monumental misjudgement and catastrophic consequence. Certainly, my eyes well up as I recall my own calamities, heroic recoveries and lifelong friendships forged through shared adversity. That time we worked for 72 hours straight reconstructing the database from two corrupted backups while customers shouted at us and threw stuff. That night before go-live when we were still bug-fixing at 4:00 a.m. Having fixed about thirty, we got all the critical ones except two. Sadly, one was in the main interface in to the system, and the other was in the main interface out of it. And then there was the order processing system for the Thai cement company. We gaily estimated it on the back of an envelope as a 6 month cakewalk for a team of four. In the end it sucked in the whole department for 3 years before wobbling into production. When the cement company tried to use it in anger, it caused a 10 mile tailback of trucks out of their factory and back onto the main highway to Bangkok. At that point they finally decided to pull the plug, revert to their old paper-based system, and never mention the dread words “automation of business process” again. Ah, great days.

Strangely, I rarely hear similar stories from candidates. I have interviewed hundreds of developers, testers, and managers over the years and 95% of them have, by their own account, never made a mistake more serious than stubbing their toe. Outside of my apparently uniquely disaster-prone universe it seems the rest of the IT industry runs more smoothly than Switzerland. Requirements and specification are crystal clear and agreed in detail with users before work begins. Estimates are made accurately, they contain sufficient contingency but are also highly competitive. Code is delivered on time, to spec, with a vanishingly small number of bugs. Test and UAT run to schedule, taking little time due to the sky high code quality, and deployment follows like clockwork. Users are delighted with the end results, and bedeck the project team with garlands of flowers, and expensive, individually-wrapped handmade chocolates.

This worries me. With all the misfortune I have endured, I had assumed I had learned valuable lessons in software development and project management. I felt I had reached a high vantage point in early middle age from whence I could dispense software project wisdom to lesser mortals who had not suffered as I had. It appeared that I was wrong. But I have recently realised that I do in fact have a unique perspective from which to pontificate. Seen as how most everybody else is busy making a success of every damn job they do, I obviously have a special talent for failure. So I have written these short pieces to broadcast that genius. If you really want to turn a software project into an absolute shambles, read on.

This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

2 Responses to Software Projects: How to Make an Absolute Mess of Them

  1. Perhaps because none of the interviewees has been let near anything of that size. I have only done in-house stuff. Sure, I’ve made errors, but mostly in my academic career, where making errors is more common than getting it right. And once you’ve finally got it right, half a year later someone will prove you were wrong anyway. But I’ve never worked on a space shuttle, or a queue of cement trucks.

    On the other hand, I’ve worked on software that runs hidden in the bowels of the OS, and if that were to crash, it could take the system down with it. But if that happens, who can link that problem to my particular work? A crash analysis won’t be conclusive, since there is so much stuff running (we’re talking Windows), and all of it has been tested thoroughly, right?

    But, I will read on. I’ve become a fan of your writing.

  2. itshambles says:

    Thanks, that’s very kind. The cement company one was hilarious, kind of. Good job it was in Thailand as the Thais are very calm people. Anywhere in Europe, there would have been riots and lynchings.
    I do believe if you review your work honestly you will pick out things that you did not do well. For example, the very very first bit of commercial code I wrote had a feature which generated telexes (it was that long ago). It worked, it was fine, but I forgot one crucial point. I dumped the telexes as flat files in a directory, and never cleared it up. So it got fuller and fuller and eventually, six months or so later, the telex generation module coughed and died as there was no space left on the disk. The customer rang in, we had a few hours of panic before we worked out what it was and cleared out some old files. We should have at that point written a housekeeping job, but we never did. Sloppy – it still makes me blush …

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s