Coffeehouse Thread

16 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Should same developer be responsible for bug fixes in past releases?

Back to Forum: Coffeehouse
  • User profile image
    davewill

    When it comes to progressing forward we tend to assign a developer to be responsible for certain blocks of code or application functionality.  Recently a bug was reported that is significant enough that we need to also go back to milestone releases in the past and make the fix there.  Should the developer in charge of that functionality NOW be the one responsible for making the appropriate fix in past code repository branch points?  How do you folks handle responsibility across code repository branch points?

  • User profile image
    spivonious

    I think it would depend on how much that section of code has changed between releases. If it's similar to the current release, then have the same developer make all of the changes. If it's not, put the developer from that milestone on it, assuming they still have some knowledge of that code.

     

    I can't give you any actual experience because our company tends to stick with the same person from original to maintenance, unless that person leaves the company.

  • User profile image
    Maddus Mattus

    Once the project has been signed off, the ownership of the code *should* be transferred to support.

     

    So, the developer is no longer responsible for it.

     

    But, in my opinion, you can hold him responsible for grave coding errors.

  • User profile image
    chrislynn5

    I think it entirely depends on your organization, or that moment in time. Sometimes the previous developer has moved on to another role, therefore, you might be able to get some input from them but as for coding the fix probably not. Or, another point might be that the original developer might not have the expertise in the first place, hence the issue, and you might want to throw a more senior coder on it. Or, if the code was written correctly (i.e. formatting, comments, documentation, and yes this is a big if), then anyone competent should be able to figure it out with a mild learning curve. Hopefully, you don't have too many branches, releases that complicate the correction. Our rule of thumb is move clients to more recent releases, if they want to stay on older (say past three) then they have to pay for it (and that includes getting code corrections). I still see clients not accepting a fixed release (even with core fixes) because of testing time etc.

  • User profile image
    magicalclick

    Well, you programed it, which means you knows it the best, including all the qirks of it if you still remember. Sometimes we make certain decisions because of certain issues within the implementation. If you still remember, you will avoid the same issue. They are not necessary documented because you can't just doc everything you experienced, that's over doc. And other people may not have the same experience.

     

    But, yeah, it is better to do some unit testing for this kind of larger development. Because you want to avoid making it worse / other people making it worse when fixing it.

     

    I prefer the person who designed it to fix it. But, you know such person may not be around or have the free time to do it.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    vesuvius

    It depends how much money you want to waste and the complexity of the problem. If the individual struggled to get the module working, then it may be worth diverting responsibility to someone else, sometimes a new set of eyes is helpful.

     

    It is almost certain that the original coder will resolve the issue quicker than someone uninured to the code, so if you don't trust him to fix bugs then don't employ him. Him may continue to create bugs that you don't allow him to fix.

  • User profile image
    blowdart

    vesuvius said:

    It depends how much money you want to waste and the complexity of the problem. If the individual struggled to get the module working, then it may be worth diverting responsibility to someone else, sometimes a new set of eyes is helpful.

     

    It is almost certain that the original coder will resolve the issue quicker than someone uninured to the code, so if you don't trust him to fix bugs then don't employ him. Him may continue to create bugs that you don't allow him to fix.

    Letting someone else fix it does provide the fresh set of eyes benefit you mention. It also means others learn the code, so they can be faster next time. It's all a balance.

  • User profile image
    Bass

    The answer is "it depends".

  • User profile image
    davewill

    Maddus Mattus said:

    Once the project has been signed off, the ownership of the code *should* be transferred to support.

     

    So, the developer is no longer responsible for it.

     

    But, in my opinion, you can hold him responsible for grave coding errors.

    Interesting.  Pass it off to support.  I've never worked in a shop where support was a shield to the techs before.  Everywhere I have worked the customer to tech relationship is always paramount and the techs push info to support.  Support is a cache to the techs rather than a shield.

     

    Once the pass off to the support group occurs would that lead to further disparity between current coding efforts and past milestone releases when in a situation where a current bug is found that warrants review of past milestone impact?

     

    Seems like divergence would occur.

  • User profile image
    cheong

    I'd think that some company would send letters to all their client, mention the bug and it's consequence, and offer them the update.

     

    This applies to companies that sells unlock code for unlocking features, so all they have to work on is the latest release and never have to look back.

     

    ==

    If that's not how your company works, I'd think it's reasonable for the developer to come up with a fix, then let the support them apply it to repository back to "as far as it could compile" or a milestone release.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    elmer

    For mine... Who ever is responsible now, has the job of fixing it now – that’s the job they’ve signed up for.

     

    I believe that having someone else modify the code you then have to maintain, is just asking for more of the same trouble.

     

    However, having said that, asking for advice and input from the original and/or previous developer(s) is something I’d see as a no-brainer, and I’d be more than a bit annoyed with any dev team I was managing, that wasted a bunch of time trying to understand something, if the answer was just a phone-call away.

  • User profile image
    Maddus Mattus

    davewill said:
    Maddus Mattus said:
    *snip*

    Interesting.  Pass it off to support.  I've never worked in a shop where support was a shield to the techs before.  Everywhere I have worked the customer to tech relationship is always paramount and the techs push info to support.  Support is a cache to the techs rather than a shield.

     

    Once the pass off to the support group occurs would that lead to further disparity between current coding efforts and past milestone releases when in a situation where a current bug is found that warrants review of past milestone impact?

     

    Seems like divergence would occur.

    When you have a project methodology you will see that you hand off code,..

     

    In a normal project cycle you hand off code to the testers. They will test your solution to make sure there are no bugs in there. When they accept the solution, you are no longer responsible for your code.

     

    Doesnt mean that you are not the one to fix it.

  • User profile image
    davewill

    Maddus Mattus said:
    davewill said:
    *snip*

    When you have a project methodology you will see that you hand off code,..

     

    In a normal project cycle you hand off code to the testers. They will test your solution to make sure there are no bugs in there. When they accept the solution, you are no longer responsible for your code.

     

    Doesnt mean that you are not the one to fix it.

    Ah.  Yes.  That makes more sense.  I've never worked for an organization large enough where the devs were just devs.  Fortunately or unfortunately that is still the case.

  • User profile image
    Maddus Mattus

    davewill said:
    Maddus Mattus said:
    *snip*

    Ah.  Yes.  That makes more sense.  I've never worked for an organization large enough where the devs were just devs.  Fortunately or unfortunately that is still the case.

    What happens when a dev gets run over by a train? or quits Smiley ?

     

    Then the knowledge leaves your company and you are left with a gap.

     

    No matter how large your company is, you should always adhere to a project methodology. It makes your life so much easyer.

  • User profile image
    ScanIAm

    Maddus Mattus said:
    davewill said:
    *snip*

    What happens when a dev gets run over by a train? or quits Smiley ?

     

    Then the knowledge leaves your company and you are left with a gap.

     

    No matter how large your company is, you should always adhere to a project methodology. It makes your life so much easyer.

    And, not that I know anything at all about your situation, but recognize that sometimes, other pressures result in marginal code.  For the longest time, I was of the impression that if I could think of a better way to do it, then the previous developer must have been a mouth-breathing moron.  Since then, I've learned that even stellar developers will develop pragmatically when they expect that the throwaway code (or simple unit test designed to show how and not be code complete) will be used to further the business.

     

    I had a manager/boss/guy-who-put-up-with-management who said to me, once "Nothing is more permanent than a temporary solution".   It guides every bit of code I've done, since. 

     

    Don't write code that could ever come back and bite you, and don't neccessarily hate on developers who had to write such code.  If the other guy is incompetant, that is one thing, but if he had a deadline and a bunch of suits pretty much forced him into writing crap code, he/she's likely not very proud of it, anyway.  Revel in the fact that you have the time to refactor what was probably a quick-and-dirty solution and do it better.

     

    Then, find a way to screw the suits Smiley

     

     

  • User profile image
    Maddus Mattus

    ScanIAm said:
    Maddus Mattus said:
    *snip*

    And, not that I know anything at all about your situation, but recognize that sometimes, other pressures result in marginal code.  For the longest time, I was of the impression that if I could think of a better way to do it, then the previous developer must have been a mouth-breathing moron.  Since then, I've learned that even stellar developers will develop pragmatically when they expect that the throwaway code (or simple unit test designed to show how and not be code complete) will be used to further the business.

     

    I had a manager/boss/guy-who-put-up-with-management who said to me, once "Nothing is more permanent than a temporary solution".   It guides every bit of code I've done, since. 

     

    Don't write code that could ever come back and bite you, and don't neccessarily hate on developers who had to write such code.  If the other guy is incompetant, that is one thing, but if he had a deadline and a bunch of suits pretty much forced him into writing crap code, he/she's likely not very proud of it, anyway.  Revel in the fact that you have the time to refactor what was probably a quick-and-dirty solution and do it better.

     

    Then, find a way to screw the suits Smiley

     

     

    I've had a french collegue who always used the line:

     

    "Matthijs, you have to understand the context in wich the code was written."

     

    The problem is the amount of passion you have for your work. Maybe to other people it's just a job. They don't want to write l33t code or be the best developer in the world. They just want to get the job done.

     

    I always keep that in mind when I chuck out their code Wink

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.