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.