Is repairing bugs created by other people in the company a good way for software development?

Question

I'm asking this because I'm currently in the position of fixing bugs that are found in modules written by other people who are still working in the company.

My personal belief is that everyone should clean their own mess because they know better what they wanted to do in those modules, and usually if someone from "outside" comes and modifies the modules it might not be the best solution.

Also the quality of the code is not something that I should be proud of ... no diagrams, no smart containers (only primitive data types in many parts), no UML ... so this leaves me, the cross platform (win32, embedded-arm) application and the debugger(s).

Should I quit/find something else? Is this wasted time?

I also raised this problem some months ago but nothing was done to fix this way of working.

I must admit that the first months were interesting and I really learned a lot.

I really need some good opinions on this. [Thanks for reading]

Answer 1

Fixing bugs in software you didn't write is a good way to become an expert in that system. But I can't tell you if that expertise will lead to better opportunities within your current company.

Answer 2

Do they know there is an issue with the code. I would just ask them, "Hey i noticed theres x issue in this code you wrote. I think the intended functionality is this. Can i correct this for you?"

Then they aren't defensive and will either explain why they did it or agree with you and decided whether to fix it or have you fix it.

Answer 3

Repairing bugs created by other people is what you will be doing for most of your life as a developer, unless you're one of the few people who only create things and never maintain them, never work on a team, never fix legacy software, and never use third party modules.

You should work on building new applications, yes, but the maintenance of applications is far more common than the building of them. Junior devs work on fixing bugs so you know what not to do in the future. You learn a lot. When it's time for you to move up, you get to focus on new development, but your experience in fixing things will always be needed, if only to troubleshoot your own code.

Give it a lot more than "a few months". As long as you're learning new things, it is not a waste of time. When the time does come where you learn nothing new, it's time to move on.

HTH

Answer 4

A vast majority of a developer's time is spent fixing and maintaining code and a lot of that tends to be other people's code. I feel its all part in parcel of being a developer.

I can freely admit that in the past I have written some terrible code in the vein of "just get it done" with (as always) the intention of going back and sorting it out, which rarely actually happens. If you come across some appalling code which can be easily improved then I would suggest trying to show the other developers the errors of their ways as well asking them why they implemented something in such a way.

Developement is about working as a team and not passing the blame or the buck. There are always going to be issues and better ways of doing things, that's the beauty of development :)

Answer 5

I don't agree. Whether you're using an Agile development process or not, responsibility for the various modules needs to be shared amongst more than one developer. Engineers cannot remain on the hook as the primary maintainer for everything they've ever done.

The alternative is that people who have worked there longer become more and more bogged down by everything they've ever worked on. When the day comes that they finally leave, you are now left with a massive body of work which no-one else is at all familiar with. It really is better to spread the knowledge around.

I know it is frustrating to fix bugs in someone else's code, particularly if the person seems to have done a very poor job in total. Nonetheless, the alternative is worse.

Answer 6

Well, I would fix and leave a code comment and if possible discuss about it with the devoloper or leave him a mail with the reasons for fixing/correcting. Anything you do to rise code/product quality is a good thing

Answer 7

Yes fix the bug. Since you found, it you care. The person who put it there may not any more. (moved to different project, is a troll, ...) If you care about the company you work for the bug needs to be fixed.

Answer 8

I spent the first year or so of life as a developer doing exactly what you're doing. It was a good learning experience but eventually it got old. I also did a stint as a QA tester for a year when the market was a little lean because I felt it would help make me a better developer in the long run - I like to think it did.

Questions to ask yourself:

1. Am I still learning/growing/making myself marketable elsewhere.
2. Do I like it here?
3. Is there room for advancement here? Do I want there to be?
4. Am I doing everything I can to advance my career.

Answer 9

Fixing bugs in other peoples code is good experience in my book, for several reasons:

1. It helps you with code reading skills, which is difficult to learn with your own code (With your own code, you tend to read what you intended it to do, rather than what you actually did)
2. It is a good way to get up to speed on an established project
3. When there is a lack of documentation, then chances are the original coder isn't the best person to fix it anyway ;) As you fix the bugs, document the behaviour as well and improve the system as a whole
4. While bug fixing, you will sometimes come across a true gem of coding written by someone else (either a truly astounding piece with a minor flaw you can correct easily, or a gem of a mistake that you can publish on thedailywtf. Either is good ;))

That's my view anyway. Also, quitting over it looks bad to the next company you try to get a job at.

Answer 10

If you maintain a "I didn't screw it up, so I don't have to fix it" attitude, you won't make it much of anywhere without an amazing entrepreneurial idea.

Answer 11

This is part of software development and teams. Yes. This is a good thing to do, especially to make yourself aware of bugs, how to spot them, how to correct them AND to make yourself known among the management. :)

Answer 12

It depends on what's really going on.

If these guys are doing a half-assed job on their code or not testing their own stuff properly then they should most certainly be fixing their crap. It's not right for a developer to write a bunch of code then dump it on someone else to fix & polish. That's just plain unfair and unprofessional.

If they're doing a pretty good job on the code and occasional bugs are coming up weeks/months later after they've moved on to other work then it's fairly typical that someone else might be expected to fix them.

Answer 13

Am I answering a rhetorical question?

Your personal belief and your job role are at odds, did you come here to possibly change your personal belief, rather than your job?

I've been in that position before - the bad code creators, still in the company, working for a different department. It's thankless.

Now if they are still in the same department, in the same position, and you're the designated 'code fixer', then that's a much more serious systemic problem.

You can't punish them for it; the best you can do is let your supervisor know that you're dealing with a mess and hope they are sympathetic.

As for your code, don't let it sink to their level lest your successor think the same about you.

If it's bothering you a lot, and discussions with your boss don't alleviate it, I'd polish up the CV and head outta there.

Edit: Sounds like you're in a tough position. If it's eating away at you, you're best off with a change.

You will always have to deal with other people's code as a developer, in some way or form. Sounds like this problem is systemic though. Best of luck!

Answer 14

I'm doing for something like more than 1.5 years this. Only bug fixing and some toolchain integration. A simple UI module which was made by copy paste because the UI interface used (beside the fact that is something proprietary) it is very very awkward. I used wxWidgets, MFC, Winapi and trust me when I say that this is the worst I have found.

To answer Chuck:

1. Not anymore. I became a debugging expert (they kind of want me to be there because I'm good at this)

2. I no longer find it interesting so I might say that besides my colleagues there's nothing to please me.

3. No - any serious decisions aren't made in this part of the company
4. I'm doing what I'm supposed to do there; although my test was a programming one I never got to use my skills to program something at least interesting.

Answer 15

In general, I think it is best when developers are required to fix their own bugs. It takes longer to find and fix a bug than it does to write new code. By forcing developers to fix their own mistakes, you are reducing the amount of time they have to write new code.

Everyone makes mistakes. The good developers make fewer mistakes than the bad ones. Since the good developers will spend less time fixing their own bugs, they will have more time for writing new functionality. The bad developers will spend more time fixing their bugs and less time writing more (buggy) functionality.

You should also realize that this should not be a 'hard' rule. It's not always feasible for developers to fix their own bugs. For example, a senior developer may not have the time (or the priority) to fix bugs, so the bug should be assigned to a Junior Developer.

Answer 16

The problem is that my "direct" boss (haha) has no power over those developers.

Not to mention that the department manager knows about the issue (as I mentioned), promised that something would change but nothing happens.

I guess I'm dealing with the wrong kind of people when talking to my superiors.

And yes, the code is messy, written in a hurry and some of the original developers don't do anything although they aren't doing anything.

Answer 17

You learn the applications you're working on: some day when the original developer leaves, you'll be the one who has this knowledge
You learn the mistakes not to to: you become a better programmer, eventually better than the original developer
With luck, you can also find good code snippets: you increase your personal code repository
You can evangelize the team: if you're this kind of guy, you can show best solutions/practices very concretely
You make the application/company better: you have an visible impact

Now it's up to you to decide if they still deserve you and if you want to stay ;-)

Answer 18

Improving the code is sometimes out of the question. The product must be presented to the customer and there is not much time for improving. Even if the original developer would have been asked to do something he will probably pass it to someone else though he knows that he is probably the only one who can do that thing fast and clean.

About code improval. Imagine this real scenario:

We have a commercial xml parser which is so stupid that it can read almost nothing but an ASCII written xml. I suggested using a open source one with a less restrictive license and nobody gave a damn. Now ... after almost 20 months guess what parser are we using ... THE SAME. Reading some RSS feeds is known to be problematic ...

Answer 19

Programmers should not have a territorial attitude towards code. So, yes, you should fix it.

That said, you shouldn't have to finish someone's work for them. If the code is still in development, it is their responsibility. If you are feeling generous, write a test to prove the bug before asking them to fix it.

Answer 20

Fixing other people's bugs is a reasonable place for a junior developer. It is also a reasonable place for a senior developer who likes that kind of thing (such people do exist). However, it seems like this isn't your only problem with the company and you've tried to improve things.

Is it time to move on to another department (perhaps the one that gets to create the bugs) or another job? It's best to find another job before leaving the current one! It's also best not to gripe so much to your interviewers as you want to. Good luck.

Answer 21

Well, I work on a company with a quite large Java software (over 1 million of lines of code, split in several applications actually). At the start, we do mostly bug fixing: that's a good way to find our way around the code. Later, they let programmers do new features as well as fixing code. Which is a good way to keep interest while keeping job done. And knowing the pain of maintaining code can help being a better programmer.

Doing only this can be a bore, I reckon.

Note: even with a good version management system, in a big application, you can hardly tell which programmer has done what part: everybody (some still there, others gone away) has altered the code one way or another. And a given coder might be busy with another task, so the bug is assigned to the next programmer. Respecting acquired experience, of course.

Sometime I track down which programmer has done a particular line of code. Mostly to ask what was the intent behind that, to avoid breaking something. Otherwise I don't care, I just fix.

There is a curious downside with version management: we maintain various versions of the software, because clients don't always want to upgrade to the latest version. So we have to integrate fixes from a version to another.

When I edit a class, I routinely fix typos in comments or even variable names, indentation (some people forget to disable hard tabs), non respected coding guidelines, etc. It was frowned upon because it adds "noise" to the fix (making hard to find the correction itself - solved by separating these fixes to another changelist) and it makes more work for integration... :-( So we are "condemned" to badly written code.

Answer 22

My personal belief is that everyone should clean their own mess because they know better what they wanted to do in those modules, and usually if someone from "outside" comes and modifies the modules it might not be the best solution.

This does raise a couple of questions to my mind:

1) When is a mess clean? One could spend years if not decades optimizing and replacing code as company dynamics change and so what was good for a small company isn't that good for a medium company, or it changes what business lines it has.

2) While the outsider modifying modules may not be the best, can you know what is best without some trial and error? I mean could the person who wrote the code for something 4 years ago be expected to remember exactly what she/he was thinking in designing a given module?

Bug fixing is a rather good starting point for a new developer in a company as this gets them to see what does the code look like, what documentation is like, etc. so that their work doesn't seem foreign when compared to others, e.g. if someone new started writing VB.Net while everyone else used C#.Net this may be heavily frowned upon.