|
A simple yes. Anything else and you're a selfish, pretentious prat.
The key is knowing what to fix, how, and when. Fixing a bug does not mean rewriting someone's code just because you don't like how they did something or the coding style. It does mean making sure you know what you're doing, and that you're not breaking something else with your change. If the change is significant, it also means that the original author knows what you're doing and why.
In other words, since this question is only meaningful in a cooperative development environment, that you respect and cooperate with your fellow team members. I've worked with the same group of folks for nearly 15 years now. We've written several million lines of code together. Our products have been successful, and there have been relatively few major disasters along the way. This only happened because we maintain a fair professional courtesy with each other while we fix each other's bugs. If it's minor, we leave a comment. If it's major, we talk to the author and make sure we understand what's going on. Sometimes the answer is "yeah, that code's always been flaky." Sometimes it's "don't touch it - I've got a fix waiting until after XYZ is ready."
Software Zen: delete this;
|
|
|
|
|
No,
The only profesional thing to do, is to report the bug in TFS ( or simular ) and let a superior decide by who and when ( if at all ) to fix the bug.
If you fix the bug and unwilingly break other code that depends on the broken code then you are responseble and should be fired.
My second computer is your linux box.
|
|
|
|
|
It sounds like your workplace differs substantially from mine. My management doesn't care who fixes the bug, just that it gets fixed. In fact, I think they would wonder why we needed them to make the decision.
Software Zen: delete this;
|
|
|
|
|
What if you were in the middle of a critical piece of code that had to be released ASAP and you worked on fixing a bug that your lead knew could be fixed by someone else who was idle at that point? If it's a big bug you would be delaying launch by fixing the bug instead of delegating.
cheers
Chris Maunder
|
|
|
|
|
I'm criticising the attitude presented by the "No, I won't fix other people's bugs" responses in the poll. My point is that you should decide whether or not to fix the bug based on what's best for the product and the company, not on whose code it is. The example you cite is obvious - 'you' should tell the lead that you're busy with the critical piece of code, and to ask the idle guy to work on it instead. For that matter, in my workplace, I'd go ask idle guy to work on it myself.
Software Zen: delete this;
|
|
|
|
|
The interesting thing in my experience is the obvious answer isn't always the path followed.
It does my head in some days.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: The interesting thing in my experience is the obvious answer isn't always the path followed
Same here. Given the nature of our product, my group is the last possible place for problem solutions. It is easy for upstream groups to delegate their problems to us, even when it obviously makes more sense to deal with the issue closer to home.
Software Zen: delete this;
|
|
|
|
|
Every person has there own coding practices, even we have standard. If the code is not readable enough to me I don't really like to fix it. However, if it's really stop my or someone else progress then only I'll fix it.
If you've never failed... You've never lived...
|
|
|
|
|
Yes, the bug itself tells me whether to fix it. If the bug requires changes in dependencies I'm not planning to work, I do not touch it. Generally this comes from the fact I do not like how the dependency is written. (Generally by personal preference to language/libraries and so on). Sometimes fixing a bug is just telling your teammate to fix it.
|
|
|
|
|
I would fix the bug with the other person's full knowledge so that we could collaborate. Sometimes junior programmers really just need to be shown how to do it correctly. Sometimes senior programmers get lazy or over think their solution.
God forbid sometimes I just miss the "reason" for what looks like a hack. BTW it generally is they just didn't want to try and figure out the clean solution or ask for help.
I always try to take a mentoring approach so that if I am right the other developer doesn't feel like I am ripping on them and if I am wrong it is an easy transition to learner.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
Normally I work under bug tracking and supporting a large number of devs and teams so grabbing this kind of work is a real no-no, it messes everything up because it happens all the time so tracking will be bogus really fast.
Anyway, if a fix is obvious & simple I'll fix it for my local build if it's stopping me but not check it in, then let the lead or PM know what's up, if you let them know you have a fix working because it was easy & a showstopper normally the assignment is switched right away and you can check it in and close it.
Just to say, many times they won't reassign the bug, even a simple typo.
tom mallard
b'vue, wa
|
|
|
|
|
Yes, I remember not being allowed to fix a null pointer bug due to it not having a ticket, and not being allowed to raise tickets (they had to derive from user issues or features).
There's something wrong with a "quality" system that prevents fixing bugs.
And of course, the user may not know why an app hangs periodically and may not even bother reporting it.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Hmmm,never heard of a system where you couldn't file a bug as a dev but obviously they exist!! ... too weird.
|
|
|
|
|
The biggest question with the way people are shuffled around between projects is if the person who wrote the old code is currently on the project.
If they're not I might have a quick chat to confirm my understanding of what the code is supposed to do (assuming it hasn't been so long they forgot); but by default I'm the person who has to fix it.
If they're on the project at the present time: I generally give them right of first refusal; which is nuanced by if it's something that's a trivial fix or complex, and if it's a critical blocker or I can wait a few days until they're able to work on it.
How I feel about the person can occasionally have something to do with it. I was a lot more likely to say "No. It's your bug, you fix it." when I had the misfortune to be dealing with a (former) cow-orker who was blasting the project with a stream of almost never worked right the first ( ...or second, or third ...) time; especially when a significant number of his fails were so severe I was unconvinced he did any "testing" beyond "did it compile" before committing the initial version.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I generally don't mind fixing someone else's bug, although I might consult them for ideas. They can fix my bugs as well.  It's good for cross knowledge training. You don't want dark hole sections of code that only "Jimmy" knows how to fix.
|
|
|
|
|
This is a tricky subject, you have to deal with ego and such. I've been in shops where its OK, and others where it is agony when a problem like this arises. To me, I always ask myself, will this problem hurt the product or company, and I let that be my guide; after all, we are there to make the company money not stroke our own ego.
|
|
|
|
|
Most of the time I fix their bugs... but they rarely fix MY bugs...
|
|
|
|
|
Because : I - the handsome one - am the one who made them, and my co-workers will fix them.
It's just unlucky to be my co-worker . . . 
|
|
|
|
|
There are just bugs in the software and they need to be fixed. The system I work on was originally written in 1990's by people who are not with the company or even in the industry any more - you bet I fix "their" bugs.
|
|
|
|
|
Agreed. Where I work we are all a team, and we do whatever needs to be done to deliver a successful project.
|
|
|
|
|
Personally I’m quite happy with that.
I appreciate a ‘heads up’, but I cannot be anything but happy when somebody is willing to put in the effort required to work on something I’ve done - as long as they also make sure that unit and integration tests are still working.
Ideally I’d also like to see a regression test that ensures that the bug stays fixed in the future too. 
|
|
|
|
|
But when the bug was actually a feature and the clever fella that fixed it hadn't bothered to read the documentation, Grrrrr!!!
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
By documentation, you mean the manual? I would understand not reading that, but ignoring comments in the code about its featurefulness would be pretty thick of them.
|
|
|
|
|
If you come from an engineering background the rule is 'when all else fails, try reading the manual'. 
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
At one job I had, every bug that came in was assigned a 'caused by' as in who's code broke the build. Developers then got assigned bugs to fix on the number they caused, but they were generally other people's bugs. The idea was that the more care you took in development the less time you had to spend in maintenance. I thought it was a good idea.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
