Fog Creek Software
Discussion Board

Not my problem...

This kinda relates to "smart and gets things done" in my mind but I'd like some opinions to balance things.

I manage projects involving different teams, each with a team leader. We use bug tracking software to keep track of bugs found and we make use of formal functional specs. Sometimes a member of one team will come across a bug / oversight in the product / spec which was caused by a developer in another team . The rule is to log in the bug track software and preferrably also to phone / email the other dev and let them know. That dev can make calls about fixing / not fixing yet but at least we have a record.

Recently I have noticed an attitude of "It's not in my code and I didn't write it so it's not my problem", even where the issue is potentially catastrophic for the project as a whole. When the issue is eventually found by the testers, a dev might say, "Yeah, I saw that around 2 months ago".

My feeling is that it is part of a dev's professional responsibility not to drop the ball. But I would think that because I am the project manager :) So what do you think?

Friday, June 13, 2003

Sounds to me like you've got severe problems and this is only the symptom.

One possibility is that you have one team that is making loads of problems and the other developers are sick of reporting it.

If you want to get people to report things, then the following must happen: the person who reported the bug must be thanked, a significant proportion of the bugs must be fixed, and the person who reported must receive feedback.

Another possiblity is that your developers have found themselves having arguments over whether a bug is a bug, and have decided that reporting merely creates problems. If they are under pressure to meet schedules then this compounds things.

Your call

Stephen Jones
Friday, June 13, 2003

Sounds like your process optimizes for not careing about other people's bugs.  Maybe you need to reward the bug finders, although then you can have folks writing bugs for the rewards.  Maybe you need to penalize the developer that noticed a bug but didn't report it, make them read a long study on how much cheaper it is to fix the bugs in development than in test or something.  Or even better, maybe you need to have a heart-to-heart talk with your developers and determine what is going on in their personal lives that makes them not care about bugs at work?  Or maybe I need more coffee...

Friday, June 13, 2003

There are only really two things that I consider "career limiting moves" on my team:

1) Saying "I don't know"

Now, wait. It's ok not to know the answer to a problem. However, too often those words are delivered with the meaning "I can't be bothered to figure it out". Which is basically another way of saying...

2) Saying "It's not my problem"

There's no such thing as "not my problem" on our team.

Ok, so you have  a problem right now on your team. You won't change it overnight. You can start by gathering the team together and explaining the way you want the team to work. It will take time, but most people will respond to the message. Those that don't.... well, there are lots of unemployed developers out there, right?

Friday, June 13, 2003

I think Stephen nailed the problem. 

First off, in a company with tight resources the person that created the bug should do the fixing -- unless it's simple, they can fix it much more quickly ($) than the finder. 

To me, it sounds like one team has grown frustrated with the other team, like maybe their bug reports are always met with resistance. 

I worked on a multi-team project once where this happened.  The other team would check in code that wouldn't even compile.  Code that would compile was buggy as hell.  After several months of fighting this behavior we decided we would try to do their work for them.  Big mistake, long story short we eventually stopped caring and the project was scrapped several months later.

If we'd had a manager with a spine it could've been avoided.

Friday, June 13, 2003

Maybe this is related to the "smart and gets things done" concept.  That is, are you a smart enough manager to figure out how to change the attitude of your developers.

There is some cost to the developer for reporting a bug: time to characterize the bug, time to make the entry to bug tracking, time to notify the other developer.  Look at feedback to the developer reporting the problem.  Does the overall project function better?  Do they get hassled for reporting insignificant bugs?  Is there any relation to their long term career prospects?  Etc., etc....

SJ point about schedule pressure is significant.  Consider the following scenario:
Dev A spends 5% of his time reporting bugs and is 5% over schedule on his own assignments.
Dev B sees the same number of bugs, but ignores them and gets done on time.
Who gets the better performance review?

Friday, June 13, 2003

hey dingbat.

"not my problem" is really short for "not my problem to fix".

it's not your team's place to fix management problems.  unless of course you are so grossly incompetent that they need to go over your head.

there's plenty of companies that need good developers, right?

Friday, June 13, 2003

["not my problem" is really short for "not my problem to fix".]

Don't be a moron. The guy said one of his developers admitted to spotting the problem two months ago and didn't do anything about it.

What, he couldn't pick up a phone and tell someone?

Writing tight code does not necessarily make you a successful developer. Releasing products that people want to buy makes you a successful developer. You think if a customer buys your product and it's buggy they're not going to blame you because you didn't work on that particular chunk of code?

Friday, June 13, 2003

Just to clarify: The person who wrote the bug fixes the bug. Not the person who finds it. But the points raised here are very valuable - I am trying to see things from the teams' perspective, not beat them up for doing the wrong thing. Then I can try to be "smart and gets things done" to fix it :)

Friday, June 13, 2003

dingbat, please reread the original article.  this is a team dynamic issue.  how can one team claim ownership over another teams code?  you think the problem is bad now, just wait and see what happens then.  Resistance will become hostility.

been there, done that
Friday, June 13, 2003

[dingbat, please reread the original article.  this is a team dynamic issue]

I suggest you do a little re-reading yourself.

The issue is developers not escalating issues that affect an entire project simply because it does not technically fall in an area under their responsibility.

A developer in our team gets only one chance to pull something like that. Sounds harsh but why do we need developers who can't look out for the whole project?

Btw, we practice common code ownership here so in fact the person who found the error could very well be asked to fix it.

Friday, June 13, 2003

You say "Recently I have noticed an attitude of ".  So this attitude didn't exist before?  Or are you just now noticing it?  If it didn't exist before, I would say that Stephen is right on the money.  We've all been on projects where certain people didn't pull their weight.  Don't beat the developers that are pulling the dead weight to get them to pull it faster, just get rid of the dead weight.

Johnny Simmson
Friday, June 13, 2003

Do the teams in question have much interaction other than the bug finding/fixing process? People are more likely to make time to help someone out (by logging a bug, for example) if they value their working relationship with the other person.

If your developers don't perceive another team's developers as part of their group and important to their success, helping that team out will be a lower priority. Getting them together socially, or to work on some sort of small project or team-building exercise might help build better relationships.

Beth Linker
Friday, June 13, 2003

"...not beat them up for doing the wrong thing"

Well, if your company has a clearly stated policy on this issue and your developers know about it but are simply ignoring it then you probably need to privately chew a few of them out for not doing the "right thing".

If you have the authority, you should call a team meeting and lay down the law on how things are going to work from now on. You don't need to act like a hardass in this meeting -- simply remind your reports that reporting bugs is part of their job responsibilities and failure to do so won't be tolerated anymore.

One Programmer's Opinion
Friday, June 13, 2003

Astarte, I think you need to do more "give the team a talk" or "get rid of the deadwood," to quote some of the suggestions so far.

I would recommend quite dramatic changes to make teams more responsible for their own code, as opposed to relying on outsiders to spot the problems. This means rearranging schedules, introducing formal release cycles, and providing slack so developers have time to design their code better first time.

Must be a manager
Friday, June 13, 2003

I had two thoughts that made me wonder if the problem isn't your process instead of your people.

1. Are you using a simple or a complex bug system? Have you considered that perhaps reporting a bug is too much work?

2. Why are you forcing a phone call? It seems like you've got a couple problems with that. First, the finding dev is assigning the bug (that shouldn't be their job), and two, you're putting them into a potentially confrontational situation by forcing them to call the coder, which may exacerbate an already existing situation of arguing bug vs. not bug.

Brad Wilson (
Friday, June 13, 2003

The only reason this stuff happens is somehow it is too painfull to report a bug- do you make the team reporting a bug fix it?

Daniel Shchyokin
Friday, June 13, 2003

It seems clear to me that the team is just not buying into the process. Adding more process at this time would only make things worse. What you need is for each team member to take responsibility for the project as a whole. Empowering the team members should help get you in that direction. Again, I am going to recommend a book at talks a lot about team dynamics, and how to overcome these types of problems: Dynamics of Software Development
by Jim McCarthy, Denis Gilbert.

Big B
Friday, June 13, 2003

You really "Must be a manager"!  Good advice.

Would you rather fix the problem, or announce that the beatings will continue until morale improves...


Johnny Simmson
Friday, June 13, 2003

So Dingbat, Simson and One Programmer all think that the developers who noticed the problem but didn't report it are incompetant morons who should be fired.

Yeah! Keep filing until morale improves!

In this environment, any developer with an ounce of sense will instantly learn a powerful lesson -- in addition to not REPORTING bugs because that is a punishing and fruitless experience, one should NEVER ADMIT to having noticed a bug. So if you see a bug, not only should you not report it, but if it is later found, you should absolutely deny having ever seen it since if you do so admit, you will be fired by the PHB.

Please tell me you guys are not really project managers.

Now some of the other posters had the right idea. It's interesting that the best developers don't feel comfortable reporting bugs for whatever reason. Find out what that reason is and see if you can't come up with a way of fixing the problem in the system.

Or you could just keep firing your best developers, like is being proposed by some serious  dumb-asses.

Dennis Atkins
Friday, June 13, 2003

Dennis:  You mean Simmson?

I don't think that!!!

Johnny Simmson
Friday, June 13, 2003

I see.  When I said get rid of the dead weight you took it as I meant fire the other team.  That's the most reasonable interpretation of what I wrote, but it isn't what I meant.  My bad.

Johnny Simmson
Friday, June 13, 2003

These posts reminds me of a frustration I had some time back.

I was getting on a quality kick, reading books about it, talking about it ... I guess I was annoying some folks.  Honestly, I wasn't trying to be a jerk, I was just excited about quality, and I guess some people felt that I was putting them down.

So, anyway, a new project comes, and I'm not coding on it, but I have some available bandwidth, so I volenteer to do some QA work.

I log a buncha bugs.  This annoys people.  They admit that I'm being helpful, but I know I'm annoying them.

By "Crunch time", after code complete, I offer to do testing again.  One of the coders says something to me like:

"Matt, you are in a unique position, because you know C++.  Not only can you log bugs, you can go ahead and fix them.  In fact, I would ask you to not just log bugs, but to -ALWAYS- try and fix every bug you log."

He repeats this statement something like four or five times, and he always seemed to to do it in front of witnesses.

Each time I would smile and say something like "Sure."

Then, I sit down, find some bugs, and fix them.  We work together on a few, and I legimately help ship the product earlier.

The working relationship turned out fine, and everything worked.  To this day, I'm not quite sure what he was "afraid of."

My best guess is that it's always easier to criticise than to do, and he start cashing the checks I was writing.  I -think- I did just thatm and it turned out ok.

Just grist for the mill,

Matt H.
Friday, June 13, 2003

The last para for my last post should read:

"My best guess is that it's always easier to criticise than to do, and he wanted me to either put up or shut up.  I -think- I did just that, and it turned out ok."

Matt H.
Friday, June 13, 2003

I have seen the "not my problem" approach alot with developers and employees in general who work only for the weekly paycheck. They have no incentive to do anything beyond what is minimally needed to get paid. I think it's your company culture and hiring practices that is the problem here.

Tom Vu
Friday, June 13, 2003

[Or you could just keep firing your best developers, like is being proposed by some serious  dumb-asses.]

Why does this sound extra-defensive?

How cares if I scare a developer into not admiting they found a bug two months ago but didn't report it? I can't friggin believe this is even a concern. Admitting you saw something TWO #$%#$^%# MONTHS ago but didn't do anything about is totally useless behaviour anyway. Are you seriously suggesting I encourage this?

And who said anything about "best" developers. If your best developers are ignoring flaws then you have an interesting definition of "best". What are your worst developers like?

You must be trolling to write something like that.

Friday, June 13, 2003

Intelligent people quickly learn not to continue doing futile things.  Your smartest developers will therefore be among the first to stop reporting bugs.

I've been in this situation and regardless of whether you think I'm any good, it was obvious flagging showstopper bugs was pointless.  I create work to the best of my abilities, and the company pays me to the best of its.  If it doesn't care about bugs, why should I?

"The definition of insanity is doing the same thing over and over and expecting different results." -- Ben Franklin

Friday, June 13, 2003

I agree with Dingbat in principle.
The problem with saying "it's not my problem" isn't that you didn't fix some specific issue - it's the attitude. This is actually the root of a lot of the old management platitudes - "There's no 'I' in team", etc.

The developers are acting like the only thing they have to care about is their little niche. Management needs to help them understand that their job is releasing the product, they just happen to have specific *tasking* that's on a micro scale. As such, anything that affects the realease is their business.

Let me say it again:

It's disturbing that they don't know this, but understandable. They need to be taught differently.

Now Dingbat, I do take issue with chastising "I don't know" - you actually want to encourage people to tell you when they don't know the answer. But they also need to be encouraged that if they don't know, they will find out the answer. The military answer is that "I don't know" is unacceptable, it should be "I'll find out". But let's be realistic. ;-)  "I don't know" is acceptable, but you'd best find out.


Friday, June 13, 2003

I worked in a company where the support dept couln't get to all the calls, some of them would leave a message, and the bad support engineers would leave the message overnight the manager, a lazy weasel if there ever was one, would then assign the previous nights support calls to whoever took them off of voice mail.

Afcourse this didn't solve the problem, since then people stopped picking up messages from voicemail altogether.

You are the manager , your JOB is to hold people accountable for what they do, and make it as easy as possible for them to do it.


Daniel Shchyokin
Friday, June 13, 2003


Then let me fire my lame ass manager that lets the other team get away with knappy sub-par performance. 


there you go!
Friday, June 13, 2003

Ding Bat, whatever you're managing, I don't think it's serious software development.

Friday, June 13, 2003

Here's my problem with the whole blame-and-punish management philosophy: managers don't exist to supervise fault-less employees who never make mistakes or errors. The job of the manager, when not in charge of perfection, is to improve - which means fixing problems, not trading one problem for another.

The fact is, honesty requires trust, and trust itself requires a feeling and perception of security; "I can tell you this, because it won't hurt me." The reality is that there are few people in the world who are ok with saying something simply because it is true, no matter how much it may hurt THEM - not other people (people who are ok with hurting other people are really not THAT hard to find). That's not brutal honesty, that's out-and-out altruism - and chances are, if you are so apt to declare "if you don't behave in an ideal fashion then you are a worthless moron", they will almost certainly not have such great attachment and like for you that they are willing to do much of anything for you that goes against their interests.

The actions of a manager always sends a message, and the message sent by simply firing anyone who makes an error is one which inspires fear: "If you are found to have done something wrong you will have no chance to improve; I will not work with you to fix the situation, I will not help you, and I won't be bothered to try to understand, and I am probably impenetrable anyway." No matter how much you might dislike the results, I can tell you EXACTLY how this will change behavior, and here it is:

- People stop caring. As they are not cared about, such that they will simply be discarded if they are found to be in any way defective, they won't care about other people either - the law of the jungle, not laws of civility.
- People look out for themselves - ONLY. Project failure, other people loosing their job, company failure - makes no difference. Since it's already been proven that they may very well loose their job anyway, they might as well just take what they can get in the short-term and go elsewhere when things go to shit.
- People become secrative. People use temporal proximity to intuitively determine cause and effect; it doesn't matter if someone is being punished for something that happened two months ago, because people will connect the most proximate action - admission of guilt or responsability - to being punished (such as fired). A simple lesson is learned: "Don't admit to anything, ever - you'll just make it worse for yourself." Don't confuse action which you don't like with actions which are just stupid; as the manager, it is your responsability to align the interests of the employees and yourself.
- As people become more paranoid and secrative you will simply become increasingly unable to know what the hell is going on, because no one wants you to know, so you are now operating in limbo.

Fear illiminates trust and crushes creativity, inspires secrecy and suppresses creativity. If you are working with manual labor and slaves, this isn't a problem, and is probably preferable. If you aren't, then I would advise you to seek to minimize fear by any means necessary - which means having to expend some effort into understanding how this whole mess got started and why the person/people did what they did in the first place, how you can keep it from happening again without breaking something else, and how you can get everything back on track.

If one cannot understand anything else, then one should be able to understand this: People greatly dislike the idea of them being discarded, even if they did something wrong, and will thus actively and ruthlessly seek to avoid it. So don't be an idiot - don't discard people because they happend to do one thing that you don't like or that causes trouble for you. And if you are perceived to have caused the whole problem in the first place, then people will REALLY hate you and actively attack your interests, because one of the greatest stresses in life is to be blamed and/or punished for something that you weren't responsible for.

Friday, June 13, 2003


OK, that's good.

Anonymous & Plutarck,

I love you both.

Dennis Atkins
Saturday, June 14, 2003

Anyway Astarte, here's your solution:

1. Allow anonymous reports to be filed in the bug tracking system. This will enable you to sidestep the issue of whatever psychological or political dynamics are at work here and go straight for the solution.

2. Assign someone (such as yourself) the job of assigning these bug reports to someone else to look into, at which point your bug tracking software should not allow bugs to be closed until they are really resolved.

Also use this as a learning experience to get a better handle on the motivations and psychology of your developers. Don't jump to conclusions about their motivations, create a system where meeting your expectations is a naturally rewarding or at least not punishing experience.

Dennis Atkins
Saturday, June 14, 2003

Also... military attitude was brought up. reading PLutarck's post was quite instructive as it lays out the reasons why we were able to wreck havoc in Iraq while sustaining minimum casualties. Iraq had an extremely authoritarian military command structure in which everyone was expected to follow orders without questioning rather than think for themselves.

Organizations that work this way are famously easy to utterly destroy. The rank and file NEVER give a shit and will not put up a fight. So you just walk in and take over.

That's why Microsoft is able to kick the butts of their competitors. Microsoft works with a flat authority structure -- just like the US military -- the little guy at the bottom is given the resources, training, and backup he needs and is able to make decisions him/herself  on the battlefield. There's a vague plan 'take over iraq' with some possible specific plans, any one of which can be discarded by anyone at any moment for a better plan.

You go in with this plan and a army of trained and empowered soldiers, and you can wipe out any force that exists, especially the highly organized ones that are too efficient to be mobile.

This goes back to the American Revolution where we Barbarian Yanks would hide in the trees like monkeys and jump at Redcoats from behind. We used that tactic to win. Ghenghis Khan used these tactics as well.

Dennis Atkins
Saturday, June 14, 2003

Also i wonder if this isn't why Linux is such a mess -- the little guys aren't empowered. Spend a year on some cool code and it gets vetoed by the Supreme god Linus Torvalds whose final decisions must not be questioned. Your effort is thrown away without a word of thanks. Make a actual mistake and get ridiculed and mocked by your peers. On top of htis you don't get paid and people who didn't wriite tho code make all the money off it. This is a system for making quality software? Or a system for sadists and masochists to get together for exploration of mutual pain synergy?

Dennis Atkins
Saturday, June 14, 2003

"Also i wonder if this isn't why Linux is such a mess -- the little guys aren't empowered. Spend a year on some cool code and it gets vetoed by the Supreme god Linus Torvalds whose final decisions must not be questioned."

The Linux kernel is hardly "a mess", and is the only place where Linus has veto power. It's a good thing he does, too, because an unstable kernel would kill Linux's reputation.

So, beats me what you're talking about here. There's nothing messy about the Linux kernel or the process of verifying code that goes into it.

Brad Wilson (
Saturday, June 14, 2003

As a guy who has spent most of his career as a lead developer, I consider it totally unacceptable to NOT call attention to an issue with the codebase for an upcoming release.  I don't care if it's a different part of the project or a different project entirely.  If it's under the banner of the development group, and you find something wrong, you run it up the flagpole.  PERIOD.

That said, I also find it totally unacceptable to allow negative repercussions to result from running said issue up the flagpole, or to make it difficult or painful in any way to do so.

You can put all the burden on the developers, but that's how bugs end up not reported.  There must be 2 components in place:  1) high expectations of professionalism from the dev team, and 2) a high degree of support from management when someone finds a bug.

Astarte, try making one change to start with:  remove the phone call from the bug reporting process.  I'm betting you'll find that your reporting rate goes way up.  Your issue tracking system should have email notification, and if it doesn't get one that does.

Saturday, June 14, 2003

Ah, developers. Always thinking about edge cases, no matter how ridiculous.

A lot of people have put forward all sorts of scenarios where not fixing a defect, or even better, ignoring it totally is justified. Interesting.

Anyway, a serious question: how do you have to define professionalism such that it's ok for you to ignore a problem in your project? I don't care how onerous your defect tracking system is (and I seriously doubt it's all that much trouble) how can you take yourself seriously as a software developer and turn your back on a problem?

To me, this is on the order of a worker on an assembly line allowing a new car to go out the door with faulty brakes because it wasn't his responsibility.

This has really been an eye opening discussion .

Btw, Philo, I don't seriously "punish" people on the team for saying "I don't know". But saying "I don't know" get's much lower marks at review time than "I don't know but I have a few ideas about how I can find out". I only have a problem when "I don't know" means "I give up".

Saturday, June 14, 2003

Are you calling futile situations "edge cases", DingBat?  If it is not a futile situation, then ignoring defects is unprofessional.

But if you are talking about all situations, futile or not, then please outsource to some other nation.  Starving is preferable to working with you, and for all developers in your country, we'd thank you.

Saturday, June 14, 2003

Hmm, I seem to have some remaining anger about that job...

Saturday, June 14, 2003

DingBat, it sounds like you like to push your shortcomings onto your developers.  It's THEIR fault for not controlling the other team.  yeah right.  I wouldn't work with/for you either

Saturday, June 14, 2003

As a side issue,

I wouldn't use the Iraqi invasion as an example of superior organisation.  It doesn't bear a seconds analysis at that level, decimation of morale had already largely occurred.  Overwhelming munitions did the rest.

Simon Lucy
Saturday, June 14, 2003

Wow, who's glad they don't work for dingbat?

Me, for one.

Saturday, June 14, 2003

"Wow, who's glad they don't work for dingbat?"


He didn't say anything I disagree with, so I'd be more inclined to work with Dingbat than I would with you.

Brad Wilson (
Saturday, June 14, 2003

The only problem I have with DingBat is that he gave the impression that he sees no problem with managing through intimidation:  "How cares if I scare a developer into not admiting they found a bug two months ago but didn't report it? "

I'm sure that came out wrong, or I'm sure I took that wrong.  I'm sure he himself was talking about an 'edge case'.  I'm sure he would rather have happy, productive developers rather than scared, spiteful ones. 

If you don't understand the implications of having a satisfied workforce, then you have probably never run a business, or it wasn't as successful as it would've been otherwise.  I'm not going into the basics of management here, there's plenty of resources for that.  But just let me say that's bad management.  Military is a special case. 

Now if he's talking about an 'edge case', then sure.  Somebody that refuses to do their job needs to be fired.  I don't think anybody is disagreeing with that.

Saturday, June 14, 2003

I would have a hard time working for somebody or hiring somebody that called himself 'the dotnet guy', unless of course he designed a significant part of the architecture.

but, that's just me.
Saturday, June 14, 2003

[The only problem I have with DingBat is that he gave the impression that he sees no problem with managing through intimidation:  "How cares if I scare a developer into not admiting they found a bug two months ago but didn't report it? "]

The point I was trying to make about that particular situation was this:

1) The originator of this thread had CLEARLY stated that one developer admitted to having seen a bug TWO MONTHS before it was finally logged and had done nothing about it.

2) Another followup stated that "punishing" (whatever you take that to mean) this developer simply taught them not to admit they had seen the problem.

3) My response: Why do I care if they admit they had seen the problem? They didn't log the problem, right? What possible benefit does their late admission provide the team? I don't want you to admit you saw a problem two months ago. I want you to log it when you find it. Admitting you saw it and didn't do anything about it is useless.

Clearly there is some confusion concerning my previous posts. Of course you don't rampage around treating developers as boot camp recruits. Mentoring is a part of the entire process. But I think we have the right to expect a certain level of common sense.

I admit I am stunned by the attitude of some of the developers here. To uncover a problem and not to do everything you possibly can to either rectify the situation or make sure it's logged is just indefensible. You cannot be a professional software developer and defend that position.

I find it highly amusing that, when presented with the possibility of "malpractice" on the part of developers, some of their peers immediately begin a FUD campaign: the defect tracking tool is too cumbersome, their managers are evil, evil, people, etc, etc. I don't care if you have to chisel the defect report on granite tablets in Sanskrit, you do what you have to do for the project to move ahead. To do anything else is unprofessional.

Troll away.

Saturday, June 14, 2003

Ah, you've hit the point DingBat.  It is common sense to report showstoppers.  So why is there a systematic tendency for people to act irrationally? 

Now, it may be that the drones are just irrational.  That is a systematic problem of hiring, but it might require individual solutions of shouting at people.  Still, it violates common sense to try applying individual solutions before knowing if there's a simple system solution.  The solution might be a simple email reminder.

Why are the teams doing something obviously wrong?  Not even the orig poster knows.  I hope he/she'll tell us when he finds out.

Saturday, June 14, 2003

"What possible benefit does their late admission provide the team? ... Admitting you saw it and didn't do anything about it is useless."

Dingbat, I thinik the thing you're missing here that many of the others see clearly that his statement is not at all useless. He is very clearly communicating an important message, one which a competant manager would instantly pick up on, but would go right over the head of a PHB.

Here is how the conversation would play out under a manager who knew how to listen to the concerns of his troops:

"Yeah, I saw that bug two months ago."

(said out of ear shot of others) "Oh wow, but it wasn't entered into the bug tracking system."


"So, is there something I should know about the bug tracking system? Something about it that isn't working?"

"Ah, I guess it's OK."

"But you thought about entering the bug, right?"

"Oh sure."

"So what made you reconsider?"

"This isn't just an issue with me but with all of us. Let's just say that certain guys here get really pissed off when management uses the bug count to decide who gets a raise. These certain folks tend to see shooting the messenger who reported them to the 'gestapo' to be the best way to unleash their frustration with an unresponsive and largely clueless system."

"Wow, I'm really glad we had this talk. What do you think of this? If anonymous bug reporting were added AND the system was changed so that bug counts are not trackable or reportable in any wayby the person who caused them, do you think we'd have a better accounting of bugs?"

"I'll personally see to it that word gets out that every bug is to be reported. But look, I'm not shitting you, if this comes back to bite the other guys in the ass, I won't be able to convince them again."

"I give you my personal assurance that management will have their act together on this issue ASAP. Thanks for your candidness. I promise to keep the details of this conversation just between the two of us."

"Well, I appreciate it. We hate not being able to report bugs and would love to see the system fixed."

"It will be."

Dennis Atkins
Saturday, June 14, 2003

On the other hand, if you work with professional robodrones on the planet of the Cyborgs, these issues will nnot trouble you because every robot is a metal man that is thoroughly 'professional', meaning he follows orders precisely and exactly. the robodrones who are unprofessional are just defective and need to be terminated with extreme prejudice. Gosh it must be wonderful working on the planet of the professional robodrones rather than working with flesh and blood humans like the rest of us. Everything must be so neat and tidy and perfect for you. Love the black boots, BTW.

Dennis Atkins
Saturday, June 14, 2003

DingBat et al, as manager with a dozen years of experience, including being somewhat of a specialist in turning projects around, I can assure you that there was a reason that that developer didn't report the bug.  The possible reasons have been gone over already (intimidated, couldn't reproduce, didn't know the rules, team dynamics, yada yada yada).

A good manager will ferret out the reason, and correct the problem.  You see, the problem isn't that the developer didn't report the bug; that is merely a symptom of some other problem.

Now, you could be right.  It could be this guy just doesn't give a rat's you-know-what.  But that's also a symptom!  Once you invest in a guy, and he's been around long enough to know the business, it's a far better course ($) of action to try to correct whatever problem is causing his apathy.  Maybe you can't correct his problem.  Have you ever had to fire somebody?  I have.  It's a horrible thing to do.  That's why I don't go to any popular places in my town anymore.  I can't bear to see the families I've affected.

Oh well, this is probably lost on all of you... I have little faith left in this industry.  And even less left in myself... jeez 10:30 on a saturday and I'm browsing discussion groups???  I must be getting old.

some old geezer
Sunday, June 15, 2003

[Oh well, this is probably lost on all of you... I have little faith left in this industry.  And even less left in myself... jeez 10:30 on a saturday and I'm browsing discussion groups???  I must be getting old. ]


Okay, it is POSSIBLE that the developer wasn't logging the defect because the tracking system is unwieldy. I tend to doubt this, probably because I've personally never seen a system THAT unwieldy, but I suppose it exists.

On the other hand, doesn't Occam's Razor suggest that the developer is simply displaying "it's not my problem" tunnel-vision?

Whatever. I agree that there's a problem to be fixed here. Coaching for the offender and possibly tweaking the tracking system. Despite what many here might think, I'm not advocating terminating someone (at least not for first, second, or possibly even third offenses) for this. Too much paperwork. But I would have thought that basic defect tracking discipline would be a pretty standard weapon in any developers arsenal. Maybe I'm wrong.

One thing that concerns me however is the idea that all this process and stuff is just something that happens to developers. Like network outages or running out of Coke. Do you think it would be all that much of a stretch to expect good, honest, developers to mention it when they find the tracking system is too heavy? And, hey, maybe even suggest a solution? Come on. Are we participants or just bystanders in this whole process?

Sunday, June 15, 2003

"Okay, it is POSSIBLE that the developer wasn't logging the defect because the tracking system is unwieldy. I tend to doubt this, probably because I've personally never seen a system THAT unwieldy, but I suppose it exists."

They do exist. In fact, most of them are painful, to varying degrees. But the worst case, by far, was at one job where the devs really only used the bug system to list their own bugs, and to mark them fixed. If we actually found a bug to go into the system, we e-mailed QA, because the bug reporting process was just ungodly difficult.

Brad Wilson (
Sunday, June 15, 2003

Oh, it's worth pointing out that the manifestation is that all the devs hated the bug system, not just one (and the boss knew it too, because... managers should be using the bug system too!).

Brad Wilson (
Sunday, June 15, 2003

If they don't like the bug system because they have a problem with the user interface, I'll agree that that's pretty lame. 

some old geezer
Sunday, June 15, 2003

Astarte, make all parts of the code the responsibility of specified individuals and give them printed descriptions of the required behaviours.

Get them used to running through these test plans before they commit modules, and give them a day to do it too. Encourage them to write test harnesses. Give them days to do this.

Pretty soon your guys will take pride in the quality of their responsibilities and you won't even have to rely on external parties to notice bugs.

Must be a manager
Sunday, June 15, 2003

*  Recent Topics

*  Fog Creek Home