Brian and Simon were both young and relatively inexperienced developers. One was fast, the other slow, both had quality issues. Too many bugs. What to do?

Simon’s Story

Simon’s story starts with a conversation. I more or less said, excluding social niceties, “You are fast but your code has a lot of bugs. How come?” Simon told me he felt pressure from management to release and release fast.

Now pressure is an interesting thing as it can be from an external source (management) but can also be internal. I have a sneaking suspicion that Simon was trying to impress given he was the new boy on the block. He may have believed getting code out fast was the way to impress.

For me, however, quality is more important than speed. This is a refrain I find myself sharing with all my teams, often repeatedly. I want to avoid the bad public relations that comes with bugs and also avoid an undue amount of rework.

I reassured Simon that I valued his contribution and then explained that I wanted less bugs. I was happy to sacrifice speed to get that quality.

I didn’t leave it at a conversation and teamed Simon up with a mentor – Peter, one of the senior developers. Peter worked closely with Simon on quality issues over a few months. Helped him take a step back and think about his work a bit more and encouraged him to take the time he needed to do it right. (Pair programming is a great way of doing this, and also sharing the mentoring load, but at the time Pair Programming was a mere glimmer in Kent Beck’s eye.)

I checked in with both Simon and Peter over time to see how it was working out. As it happens it worked very well. Simon changed his approach. He took a bit more time but his bug count went down drastically. He was still fast and now he was also good. Within two years Simon took over Peter’s development responsibilities when Peter move on to other things.

Brian’s Story

What I didn’t do is fire Simon. But I did fire Brian. Not at first but eventually.

Brian was a friend of the family of one of the partners. Nice guy but slow. Painfully slow. And to cap it off he also produced a lot of bugs.

My natural inclination is to try to match each person to a role that exploits their strengths and avoids their weaknesses. So I went looking for a niche for Brian. Given he had personal connections to one of the parters I had to try particularly hard in his case.

We tried getting Brian working with others and working by himself – working with someone was better. We also tried different technologies. Brian was most comfortable with end user computing tools supplemented by light weight programming; probably no coincidence that these were tools he’d used at college. This tool set was what we used for doing small commissions. This was the best niche I could give him. Unfortunately the speed was still poor and the bugs numerous.

Brian just did not have a talent for programming. He had studied it. He liked it. Enjoyed it. But just wasn’t good at it. He should have chosen a different career, one more aligned with his strengths.

To counter the poor quality I had to spend a lot of time checking what Brian produced and nudging him towards better quality. But the cost-benefit of that scenario didn’t add up. The commissions were low value. Brian was cheap but I was expensive. It needed a lot of my time to get anything like good quality from Brian.

Trying to overcome his lack of talent was waste. A waste of my time, the companies money and even Brian’s time.

So despite political fallout I sacked him.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.