Fog Creek Software
Discussion Board

Managing bugs in other people's code

This problem has arisen a few times in my career, and it's proven to be a real stumbling block for me.

I frequently develop applications or middleware that uses common library code owned by somebody else in the company. And every now and again, I come across a bug. Most of them I can work around or think logically around it, and wait for an update at some later time, but just occasionally I find one that renders me unable to continue.

The trouble is, the developer owning the library code is busy scheduled on some other REALLY important task right now and doesn't want to drop everything and fix it.

In the past I've had my head ripped off because I've found a copy of their source code, taken a local copy of it, and "played" with it to see if I can work out what the problem might be. (And I should emphasise that I never intended to release the local copy to anybody, fully aware that I didn't own the code, but rather to give the owner some helpful pointers as to where the problem might arise).

Head-connecting-to-desk moment.

How can I manage this better? It's frustrating to be stuck against a brick wall feeling uproductive and unable to bump my problems up the priority ladder...

Better than being unemployed....
Monday, December 23, 2002

That sounds like a nightmare. You shouldn't be getting beaten up for fixing bugs in somebody else's code if it stops you from doing your own work, imho. Developers don't own code, the company does.

If it were me I'd do my best to explain that it would be better for all parties if I fixed the bug in the other guy's code to make my life, his life and anybody else using the libraries life easier. If he was free right now and he'd fix it now, then I don't see what difference you fixing it now is.

If it really is preventing you from working now (and you can't do something else until the developer fixes the bug) then surely that's reason enough...

John C
Monday, December 23, 2002

If you get stuck, and the other guy won't help, escalate. Stuff like this is what managers are supposed to be for. Tell your project lead "I can' t continue with this project because of this bug. Here's our options: I fix it myself, or we wait for the original group to fix it." Then let your manager make the call.

Chris Tavares
Monday, December 23, 2002

"Code ownership"... where you have to wait for someone else to correct their errors is always a bad thing.

But I agree... escalate and let your management decide if the product is worth the prestige of the code owner.

Joe AA
Monday, December 23, 2002

No can do.

Because it was the manager who tried to rip my head off. Not the programmer. It happened at my last company, and at this one, one of the managers whinged that I "seemed to like to rewrite released code as and when I felt like it".

No I don't - I'm fixing broken code! Aaaargh! I did once raise it right up to the company director who jumped on everybody and said "do it now, or you can't go home" - but that was too much hassle to just get one damn bug fixed.

In their possible defence, the library code (in both cases) was common to several products and would have to be regression tested against everything (like, so what? You always have to test things!) and I'm not as au fait in the particular API calls used (but any decent programmer can spot an "off by one" error in any code).

Fortunately - somebody's now looking at the latest bug with due care and attention...

Better than being unemployed....
Tuesday, December 24, 2002

Dont know the language you are dealing with, but is extend and override an option?

Daniel Shchyokin
Tuesday, December 24, 2002

Or wrap and delegate for that matter?

Daniel Shchyokin
Tuesday, December 24, 2002

Sounds like you have a serious problem with your management, but now for a helpful solution.

If you've fixed it in a local copy of the code why not send the owner a diff so it's trivial for them to fix it?

Miles Barr
Wednesday, December 25, 2002

Yup, that's what I've done and they've done it.


However, I seem to have put more time in to do this, and the code owner has just had a straightforward list of instructions.

Better than being unemployed....
Friday, December 27, 2002

*  Recent Topics

*  Fog Creek Home