9

I just came out of University and have been working at this company for roughly 8 months, while I was given the title of developer, most of the time I have spent on is fixing and debugging other people's codes.

I always wonder why isn't the original developer's responsibility for fixing his/her code. I understand that if the original developer is no longer present, then the other developers have to take over the work, but what if the developer is still working as an employee in the company?

One may argue that it is beneficial to the new developers as they see it as an opportunity to learn, and I agree with that, but what if the complexity of the problem/issue of the code is very steep? In my case, most of the codes they assigned me to fix are non trivial problems, and it always ends up myself asking the original developer questions regarding the code. Why can't the developers who created it fix the existing problem if they understand it so much better since they coded it? And the problem I am referring to is not some trivial problem where you can fix it in a day or two,but problem that requires a deep understanding of the code in order to come up with a solution.

What is the reasoning behind this and is it common in the software industry?

Improve this question
2
  • 2
    Yes it's common. You are expected to bring this up with the developer whose code you're fixing.
    – user16764
    Commented Feb 22, 2013 at 18:06
  • 1
    See also Graduate expectations versus reality - in particular, note the bit on maintenance. Realize the new person often gets the "fix this" because the rewards of "new development" go to people that (in theory) have a better idea of the architecture needed and have more seniority to do the fun stuff (new code is fun).
    – user40980
    Commented Feb 22, 2013 at 18:55

6 Answers 6

Reset to default
11

I think the main reason you'll see justifying this sort of thing in the broadest sense is the "bus factor". If the same person writes and maintains a piece of code in perpetuity, nobody besides that person will have any clue how it works, which is trouble when that person leaves. So having new developers fix bugs to get started is often justified with that rationale.

Personally, I think the justification is unlikely to match the reasoning. I think the actual reason that this happens with newer developers is that departments honestly don't really know what to do with them, don't really have a comprehensive training program and are nervous about tasking them with major features. So whatever you might be told, it's probably a sort of default way to have you prove that you're capable of handling stuff and hopefully learn a thing or two along the way.

I personally think there are much better ways of accomplishing this, but it's a way, and I suppose it does sometimes work, after a fashion (notwithstanding the risk of boring newbies into quitting for greener pastures).

Improve this answer
2

Other commenters have already covered some important points - I'm talking from the position of someone who worked for a while in a development team specifically tasked with maintenance of shipped code. Pretty much all of your questions came up time and time again.

There are many things that could be going on. You pointed one out - the original developer may have left the company. Another possibility is that, while the original developer is still in the company, he/she has long since moved on to other things, and no longer has that stuff in working memory (especially if the code has changed quite a bit since they were working on it).

What we had to deal with, for instance, is that the product team had very aggressive schedules for delivering next versions of the product. If they also had to work on bugs in the existing versions, at least so the reasoning went, they wouldn't have been able to meet their schedules. I guess this point could be argued, but the reality of the corporate software world is that getting stuff out the door trumps everything else, including observing all the best practices of software engineering at all times. "Tradeoffs" is the vague term under which fall all the unpleasant compromises us developers sooner or later have to do in those environments.

On the other hand, however, fixing non-trivial bugs requires you to really learn a lot about the codebase. It is painful, sometimes demoralizing, and oftentimes overwhelming. But how exactly do you think you're going to become a subject-matter expert on a software project? You can spend days reading the code for your edification, but that kind of code perusal doesn't really stick as well as having had to "battle" with the code in order to fix a problem. Researches continually trump the motto that we learn by doing. Sadly, unless you're in a startup or a new team, this means that you're usually joining a software project which has been around for several releases, and has real customers with real complains that need to be addressed. This implies that you will be fixing bugs first before you're given functionality to add/redesign.

What's really important is to communicate regularly with your manager and express what you want to get out of the job, and see if the business can actually accommodate for your goals at the moment. Hopefully, the answer will be yes. Stick around for a while and gather all the experience you can from your current team. If the answer turns out to be no, and you're a good developer, you will have many options. But do not discount the experience you gain by fixing bugs - I'm now into my third software job and I have to write tons of code. Fortunately, a lot of it works from the start because I've spent so much time identifying, fixing, and trying to prevent bugs.

Improve this answer
2

There are pedagogical reasons and risk factor reasons, but mostly it's just math. Most programming work is maintenance, and those who have been at a company the longest have generated the most code that needs maintaining.

Consider a one man software company. After 10 years he hires someone to help him out. If 90% of the work available is maintenance work, what is the new guy going to work on if he can't touch the old guy's code? On a larger team the effect is harder to quantify, but that doesn't mean it's not there.

So try not to get hung up on who's responsible for what code. People get attached to "their" code and don't give it up lightly. In a few years there will be code you want to preserve your responsibility for, but you just plain won't have time.

Improve this answer
1

We have to admit that software developers spend much more time reading/understanding code than creating it. And from my personal experience, the better is company you work for the more code you read. So the fact that you have to deal with others' code so much shouldn't surprise or confuse you at all.

And this seems quite natural. In order to learn something you have to see how its done. There aren't many companies where pair programming is practiced and novices are taught this way. Most of the time you learn new techniques, patterns, company's coding style etc. by reading others' code.

And the most efficient way of understanding code is actually working with it: debugging, refactoring, fixing bugs. This is a common practice if you are to take the ownership of the code.

The possible reasons why the original developer doesn't fix his/her bugs might be that

  • the bug has little priority, and the developer's current task is more important or urgent.
  • the developer hasn't worked with that code for a long while and it would anyway take them some time to recall their old code.
  • the developer is very busy with something complicated and needn't be interrupted.

P.S. I think you're lucky that the original developer is there to answer your questions.

Improve this answer
1

Erik is spot on.

Also management want to hedge their bets by getting all developers familiar with certain aspects of the code. Just because one person wrote some code does not automatically make them responsible for it whilst they are working there. Quite the opposite, the more developers that maintain it, the more chance of bugs being spotted and improvemnets being made. Everyone likes to leave their mark ;) if you know what i mean. Another view is that the code is owned by the company and not the developer. It makes a project managers life slightly easier if their have more developers to choose from for a certain task. They are probably just easing you into to their code libraries and at the same time testing your ability. They would be crazy letting a new employee near anything that could cost the company money, certainly for the first 6 months or so.

Improve this answer
0

good answers, all; here's another angle -

it may be simple economics

it may take you 5 times longer to find and fix a problem than it would the original developer, but the work the original developer is doing in the meantime provides far more revenue to the company

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.