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

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 2

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 3

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 4

I'm a senior developer who's part of a large software development team working on a large software product (tens of millions of lines of code). At the moment, we're a few months away from a release and I've been assigned to fix bugs in areas that I am unfamiliar with. Due to changing priorities, my current project was put on hold so that I could spend time fixing bugs. And yes, 99% of the developers who created the bugs, still work in my department, but they are lucky enough to find themselves working on "important" projects.

I understand that:

1. Fixing bugs caused by others in unfamiliar parts of the code can be a way to learn about other areas.
2. The reality of software development in a large team setting may result in these types of reassignments and sometimes there's no good choice.

However, fully recognizing the above, I feel strongly that accountability is the best policy for these reasons:

1. All developers are not alike and management doesn't always seem to recognize that. People have different skills and goals. For example, not everyone excels at or wants to be say a GUI developer or a services developer. Software is complex and different areas require different specializations (e.g. services, GUI, algorithms, web stuff, deadlock management, etc...). To make an extreme example, it's like expecting your Dentist to perform a rectal exam. Some amount of specialization makes sense.

2. Given that we're trying to get a release out, it's very inefficient to assign someone completely unfamiliar with an area to work on that area.

3. The person who created the bug typically does not get any feedback that their code had bugs. This does not help them create better code in the future.

4. For many developers, this activity reduces job satisfaction and that should be taken into consideration.

5. It's more likely that an outsider to the code will make a patch rather than a fix that's consistent with the design. It happened to my code once and I would have been happy to fix it myself rather than let someone else compromise the design integrity at expense of a quick fix. I will say that code reviews can help, but they're not perfect.

Answer 5

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 6

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 7

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 8

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 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

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 11

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 12

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.

Answer 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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 21

I don't see the problem:

If you're taking the payCheck, you do what you're told and put your personal agenda aside.

If you can't do that, find a different source for your payCheck.