Sometimes in software development, a project can seem to go perfectly well, but still result in disaster. This is the story of my first major taste of such a project, how I dealt with the immediate fallout, and the lessons I learned in the process.
This is a fairly long post, so I’ve tried to keep it entertaining - but if you’d rather skip to the end for the ‘Pro Tips’, feel free (though you will be missing out on a good story and some excellent imagery, if I do say so myself).
Names and some details have been changed to protect people’s anonymity.
One Angry Man
It was an unremarkable morning at the end of a grey British summer when The Call came. Though it wasn’t a daily occurrence, there was nothing particularly unusual about receiving a phone call straight to my desk - I had several clients who had my direct number - but in the world of consultancy, there were really only two possible reasons a client would reach out to me rather than their primary contact, which was usually a salesperson. Either the client had an idea for something new they wanted to add to their system - the good kind of call, which meant I could control what happened next and earn a little commission - or the client had a problem and knew that the fastest way to get it fixed was to start a fire - the bad kind of call. This, unfortunately, was the latter.
“Tom, we’ve got a serious problem here - this doesn’t work at all!” announced the thick, Scottish voice before I’d managed to place the phone to my ear. Terry. I winced. His voice was loud enough that everyone around me could hear.
I liked Terry - a big, burly man approaching retirement, who dominated whatever room he was in. His job was to manage the distribution hubs for a national retailer - and my job, in this case, was to make his life easier and build a system to allow him to digitally track the packages going in and out of the warehouses he managed. We had a good relationship, but he took no prisoners when it came to getting what he wanted - which was more of a problem for management than it was for me. Most of our conversations were based around relatively minor technical details and UX concerns: the overall design of the system we were building had been agreed months before either of us had been introduced to one another.
Though we occasionally had difficult conversations, I appreciated Terry’s blunt assessment of things he didn’t like, and I like to think he respected the fact that I was always ready to hear him out and give him an honest response, even if I had to disappoint him. He had a reputation amongst my colleagues for being difficult, but I kind of enjoyed the fact you could have a bit of a back-and-forth with him. It was more interesting than most of the meetings I had to sit through, at least. We’d deployed the system he was calling about just a day or two earlier.
“Oh - I’m sorry to hear that Terry, what seems to be the problem?” I replied, switching into that sickly-sweet Customer Service mode. Probably, in hindsight, a mistake.
“WELL IT DOESN’T F***N’ DO THE JOB!”, he bellowed, suddenly irate - probably didn’t appreciate my tone. All around me, heads turned. Eyes widened. Faces (well, mine) reddened. Uh-oh.
If you’re in a technical role, there’s a good chance you’ve heard “It doesn’t work” before - and there’s an equally good chance that you’ve dealt with such complaints with a request for more specific information, error codes, logs - something that actually helps you understand the nature of the problem. It’s not unusual - but it’s not pleasant to have such a complaint shouted at you by a 7-foot man who could snap you in half without strain and sounded ready to do it.
“OK - can you tell me what exactly is going wrong? Where in the system are you seeing the problem?” asked I, naively. The project involved several major components - databases, web frontends, mobile applications, and domain-specific hardware. There were many potential points of failure - and something going wrong somewhere in the mix was to be expected on occasion. But not, ideally, days after rollout.
“The problem is the f*****g system, Tom! It’s useless to us! First of all…”
An hour and a half, pages of notes, and several pints of sweat later, we ended the call with an agreement that we’d set up a meeting to discuss what had gone wrong, and who needed to be thrown to the wolves as a result. Obviously, the unspoken assessment was that it I was I, in all my early-20s fresh-faced innocence, who was to become lupine luncheon.
Keep reading with a 7-day free trial
Subscribe to Not A Robot to keep reading this post and get 7 days of free access to the full post archives.