4

I work in software development and have worked on two projects with the same piece of software being used in both, but each are slightly different. The second was built off the first's code with functionality changed a little.

The software is an add-on running in the background for another software application. The first project's version didn't crash when the main application was closed. The second project's version crashes every time the main application is closed, and causes the whole system to hang for 30-60 seconds, a serious problem. I know the crash behavior is not correct: one, being a software developer I know this is obviously wrong; and two, the first project's version didn't have the problem.

The first and second project versions of the software have been developed by two different developers. I have tried talking to the second project's developer several times about the issue, but they have come back basically saying it's not a problem and that we should find a way around it, like creating a special button to close the add-on running in the background before clicking another button to close the main application.

I don't understand why they don't see the problem as I do. This developer is a manager level developer above me. How do I go about explaining it to them? I was hoping someone else would have noticed it by now as we have demoed the software once already to a prospective client. I thought about talking to my manager about it. I also considered talking to the project lead about it and seeing if he'll look at the problem and "notice" it and talk to us developers about fixing it.

How do I handle this in the most professional way? I do not want to create an "atmosphere" in my office or change any of the relationships I have. I have worked with this developer for a year now and will probably be working with them for the foreseeable future, but that doesn't matter as I don't want any relationship to change whatever I do.

Improve this question
11
  • 1
    do a private demo with your boss and ask if he sees anything he would like to change. (In the demo, explicitly show the crash and hanging) He may end up wanting it to be changed, and he will order the change, not you, so people can remain happy with you.
    – TheOneWhoPrograms
    Mar 24, 2014 at 11:58
  • 1
    You can then likely raise your concern with him if he is bothered by the crash and mention you would like to make sure he doesn't mention you when talking about it. At that point you already know your boss is unhappy with the crash and is likely thankful to you for pointing it out.
    – TheOneWhoPrograms
    Mar 24, 2014 at 12:10
  • 1
    Good answer Joe, A bug tracking system would help managers see the problems and their severity without having to personally notify them of the problems. Demi, may it be more worth trying to advocate for bug tracking rather than bringing up the problem? ug tracking is very important, even in prototyping as thats were many bugs are introduced.
    – TheOneWhoPrograms
    Mar 24, 2014 at 12:47
  • 2
    You can personally enter it into the tracker as you were requested by your manager to enter all known bugs into the tracker. No one would be able to say "hes a jerk for entering a known bug into the bug tracker", you were simply noting it down.
    – TheOneWhoPrograms
    Mar 25, 2014 at 6:55
  • 2
    If it gets closed by the developer then you have it on record that the developer was notified and that he personally closed it. Also, if you make it a high priority on the bug tracker your team lead may notice its sudden status change and may bring more questions forward to see how it was fixed or if it was fixed. If not, then you are in the clear anyways; you brought forward the issue, put a high priority, and another developer closed a high priority bug without talking to team lead; he should be worried, not you.
    – TheOneWhoPrograms
    Mar 26, 2014 at 10:49

4 Answers 4

Reset to default
6

This is the primary purpose for bug tracking systems.

Once a functionality is marked as complete any issue with that functionality not performing as defined is a bug. Even if your team doesn't you should take the time to properly document the bug.

Now with that said the ROI for fixing a bug might make it low priority even if it's something as cringe worthy as crashing on close. So if the bug isn't prioritized that's something you have to accept. (Though it's perfectly fair to attempt to convince who ever handles assignments/sprint planning to make it a higher priority)

If a developer closes/removes the bug as "by design" or "Not a bug" when it so clearly is, even if that developer is your lead, you should first talk to them, if they continue to stone wall you escalate it appropriately. (Demo the application and make sure to show the crash and lock up) ask if that's how they intend the program to work. If not, it's a bug and needs to be left open.

If the manager has it closed/removed for the sake of manipulating bug counts or because crashing is deemed acceptable behavior for your application... well... your manager is crap then... And dealing with that is a completely different issue.

Improve this answer
3

So to solve my problem, I simply fixed the code myself and let the developer know what I did. They replied saying they had tried what I did but it was causing the software to crash. I never saw anymore crashing. I did this early in April, I should have done this a long time ago.

Improve this answer
1
  • Sometimes, that's just the easiest way.
    – Bobson
    May 28, 2014 at 20:01
0

It's obvious that you are going to have to escalate the issue to your manager since Developer #2 is not listening to to you, he is not going to fix the problem unless prompted from above and the solution he is pushing on you sounds like an kludge. He is trying to claim that he is done with the project when he has obviously not finished. Again, somebody from above him needs to tell him that he has not finished and that kludges are not acceptable. The status quo could blow up if the client comes back unhappy and there could be finger pointing from Developer #2, so you need to establish some kind of paper/email trail that you raised the issue and tried to resolve it in a manner acceptable to the client.

Improve this answer
0

You could point out that both, a workaround and a definite solution need time to be implemented, hence a proper fix would be the first choice.

I assume the reason for the crash is unknown or you would already have repaired it. You could argue that the cause could also interfere with other parts of the software and causing an additional amount of work at a later time.

If you truly believe that this problem need to be fixed properly, escalate it. Talk to his boss and explain the situation. Remember that you are working for the companies interests and not for the guy who wants to go for a workaround. He is just entrusted with team lead, but doesn't necessarily always make the best choices.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .