An email arrives from a client with a bug report. It’s not critical and I’m busy working on something else. What I should say is “raise a ticket and we’ll investigate in due course”, but still it’s a struggle to stop myself from jumping out of my current task and straight into it.
Partly it’s that I don’t want to be the jobsworth who tells people to follow the process, and partly it’s that I’m not good enough at saying no, but I end up being too helpful for my own good. If you get a reputation as someone who helps people, people will ask you for help first.
But I don’t think it’s just me. Developers need to be carefully shepherded away from trying to solve every problem.
We’re mostly somewhere on the OCD spectrum, so quirks offend our sense of neatness. We want to understand and categorise the world, and can’t bear the idea that there are bugs anywhere
We’re like kids, getting so enthusiastic about having a new toy to play with (or a new problem to solve) that we forget about our old toys (and our old bugs).
Maybe the new bug is interesting and/or challenging, or maybe its just that new problems are inherently more interesting than whatever you’re currently working on.
But It’s too easy to get sidetracked, and forget to make sure that the backlog is properly prioritised. Some issues should be put to the bottom of the backlog, or rejected as “won’t fix”. Maybe there are workarounds. Maybe the bug only exists under some specific set of circumstances that is unlikely to ever happen in production. Maybe the impact of the bug just isn’t worth the effort that it would take to fix. Or more significantly, maybe the issue is out of scope. Nobody is going to get paid for solving that problem.
On the other hand, we need someone keeping an eye on us to make sure we solve every relevant problem. Has it been tested in IE? All the supported versions? Has it been regression tested since all those other bugs got fixed? Like all the new styles to fix the IE bugs?
For me, this is one of the most important jobs of the client liaison middleman - depending on the organisation their job title might be project manager, account manager, engagement manager, producer.
They need to keep the developers focused, and part of that involves being a gatekeeper to the developers, a troll under the bridge that will stop clients from unnecessarily pestering them.
In some places, there’s a strict policy of clients not talking to developers, but this can be a real barrier to the flow of information. So maybe the rule should be that developers are allowed to contact clients, but contact from clients should come to the middleman.
The middleman needs to be technical enough that details don’t get lost in translation. They need to keep an eye on the commercial side of things, and should be unafraid of saying no to the client.
I need to keep reminding myself that it’s OK to have a big backlog. As long as you’re getting through tasks, and keeping quality up, it’s a sign that your services are in demand, and hopefully means that your job is secure.
It’s easy to get addicted to ploughing through a task list - I’ll just fix one more issue and then leave the office. There’s also the mentality of “I’ve started, so I’ll finish”, which ends up applying to the list rather than the task.
Bugs will still be there tomorrow, and you should go home and get a good night’s sleep.
Backlog tasks are like a box of chocolates - it’s tempting to try and eat them all at once, but if you do you’ll feel sick.