Bug Management

  • Comments posted to this topic are about the item Bug Management

  • For a cloud vendor contributing back to the root project totally makes sense otherwise you'd have to reapply your fix every time there was an OS update. Also if you are spinning up Google Compute Engine instances you'd want your install image as simple as possible.

    Not sure if it would make sense for AWS to patch Kafka given AWS's own Kinesis product though AWS does offer Kafka as well.

  • "Some use junior developers to do bug work."

    And possibly herein lies the problem with bugs.  My personal feeling is that those who create software should be the ones who have to find and fix the problems in their own work.  This would in turn lead to better development effort.  If it takes "junior developers" to fix bugs, maybe we have the wrong "senior developers".   No one should be allowed to develop software and then just throw it over the fence and not worry about it.

    The thought crosses my mind that maybe debugging is actually a greater skill than development.  I remember many times having to take on the job of finding and fixing design and development problems in production code, and then having that effort hindered by reluctance to actually implement fixes.

     

     

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • skeleton567 wrote:

    And possibly herein lies the problem with bugs.  My personal feeling is that those who create software should be the ones who have to find and fix the problems in their own work.  This would in turn lead to better development effort.  If it takes "junior developers" to fix bugs, maybe we have the wrong "senior developers".   No one should be allowed to develop software and then just throw it over the fence and not worry about it.

    Not all bugs are created equal nor are the root causes of all bugs nor are all development teams.  Some bugs are trivials, which is why they weren't caught in testing.  Some bugs are the result of something unexpected in production or something changing after deployment which is hardly the fault of the original developer.  And by the time some bugs get discovered the original developer may or may not even be available either due to other work or employment situation.

    Fixing bugs is often also a good chance to let a junior developer familiarize themselves with a code base before tackling something harder.

  • ZZartin wrote:

    Not all bugs are created equal nor are the root causes of all bugs nor are all development teams.  Some bugs are trivials, which is why they weren't caught in testing.  Some bugs are the result of something unexpected in production or something changing after deployment which is hardly the fault of the original developer.  And by the time some bugs get discovered the original developer may or may not even be available either due to other work or employment situation.

    Fixing bugs is often also a good chance to let a junior developer familiarize themselves with a code base before tackling something harder.

    And bug fixes are also a good chance to let 'senior' developers learn to be more careful and thorough.  I understand the employment situation, but 'other work' should not be an excuse.  In my world you clean up after yourself before you continue on and make another mess.  That's my priority.

    There is also the aspect of familiarity and knowledge about the original intent of the development effort to be considered.  In my 42 years in IT, one thing I learned is that it isn't good to allow original developers to walk away from their products if it can be avoided.  This only leads to more carelessness.

     

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • skeleton567 wrote:

    ZZartin wrote:

    Not all bugs are created equal nor are the root causes of all bugs nor are all development teams.  Some bugs are trivials, which is why they weren't caught in testing.  Some bugs are the result of something unexpected in production or something changing after deployment which is hardly the fault of the original developer.  And by the time some bugs get discovered the original developer may or may not even be available either due to other work or employment situation.

    Fixing bugs is often also a good chance to let a junior developer familiarize themselves with a code base before tackling something harder.

    And bug fixes are also a good chance to let 'senior' developers learn to be more careful and thorough.  I understand the employment situation, but 'other work' should not be an excuse.  In my world you clean up after yourself before you continue on and make another mess.  That's my priority.

    There is also the aspect of familiarity and knowledge about the original intent of the development effort to be considered.  In my 42 years in IT, one thing I learned is that it isn't good to allow original developers to walk away from their products if it can be avoided.  This only leads to more carelessness.

     

    /shrug I just think the situation is more nuanced than anything wrong with something you wrote is automatically your responsibility to fix.  Especially since as I noted this is not always or even often due to carelessness.

  • I've seen both arguments. There's a good argument, maybe the best one IMHO, to have senior developers mentoring junior developers in building software. Which then leads to senior people catching some bugs  in dev, but also working on bugs after the fact and learning what people are doing wrong.

    I tend to agree with Rick here. We want senior people to make software better, which means they need to be in a position to do that. If they build software and can't/don't/won't take feedback from bug fixers, we have a problem. If they are the bug fixers, or partially them, then they should be learning.

  • I feel like there are some developers that really like tracking down and fixing bugs and others that really don't - regardless of whether they are junior or senior.  There are pioneers and settlers.  A good team needs both.

    The three biggest mistakes in life...thinking that power = freedom, sex = love, and data = information.

  • It's not so much tracking down and fixing a bug that does it for me as removing an annoyance and/or distraction.

    Simply being able to decide for myself to fix a bug and not having to justify the need and burn hours in endless meetings doing so is a tremendous motivator. Obviously you need a robust CI/CD pipeline and test suite to do this safely.

    I find that having a bug you aren't allowed to fix hell on earth. Yes we could take the stone out of your shoe but we're behind schedule on a walk around the sun to meet the moon.

  • I personally find myself frustrated with "lets just ignore it" being considered a valid response to an identified defect.

    To build on the example above: I think we should either get the pebble out of the shoe or rearchitect the solution to include a "warning pebbles inside" sticker on the shoes and make sure we make our feet pebble-proof.

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply