Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am a programming intern who has worked for a company for 6 mnths now (this is my 1st programming job so I have 6 mnths experience). I am a 1 man team right now & I am creating a mobile application using the Mosync C++ API.

I am looking for advice on how to report a bug to a boss who is not a programmer. I have had trouble in the past explaining the gravity of a bug/programming issue & he will say "just work on something else for a couple of days" with the expectation it will be fixed in a couple of days anyway. The major problem is that he thinks that amount of effort directly relates to the outcome of solving a bug & if it is not fixed after a couple of days its due to lack of effort or skill

How can I explain that I cannot determine how long a bug will take to fix, & that if it does take a long time to fix its not related to lack of effort or skill?

Some background information: I have a bug in a the current project(mobile app) I am working on. The mobile app was complete but my boss wanted me to add features to it. After adding a feature the app now crashes after transitioning screens X amt of times & it is very difficult to replicate the bug(seems random & intermittent) but it is also very serious because releasing an app that randomly crashes is obviously very bad.

As a young programmer I know that my experience is most likely to blame for an error in my app & that there is much I could have done to avoid issues like this such as regression tests, maybe better app architecture design to allow for component based development(add new features that work well with existing ones). But I also know that bugs are a fact of programming & it will always happen.

share|improve this question
add comment

3 Answers

Tell him the truth. That you are stuck and don't know how to find the bug. Tell him that you need an expert / mentor to help you out.

Yes, the bug is probably your fault, in a sense. But if you are too inexperienced to diagnose it / understand the root cause / understand what your real mistake was, then blaming yourself (or the boss blaming you) is pointless.


FWIW - bugs that are hard to reproduce typically turn out to either involve thread-safety issues or memory management issues. In this case (an interactive C++ app) it could be either. It is possible that your recent changes have caused the bug. It is also possible that the bug was already there, and your changes simply make it more likely to occur.

share|improve this answer
    
thanks for the reply, but I had to laugh when you say I need an expert/mentor, I would LOVE that, really I would, but I know his face & reaction when I say that –  Mack Jun 27 '11 at 10:21
3  
@Mack: don't call it expert/mentor, call it code auditor. His job is to audit the quality of your code and provide second eye's feedback on possible problems that you might have missed since you're so deep into the code. A second eye is always helpful even to expert programmers. –  Lie Ryan Jun 27 '11 at 10:41
1  
If the only person on the "team" is an inexperienced intern that says the boss is a cheapskate who doesn't want to pay to have things done properly (no offense meant to the OP), so it's very unlikely the OP will be able to get any assistance, let alone a senior developer. –  Wayne M Jun 27 '11 at 12:45
    
@Mack - if your boss is not going to provide you with the means to get the assistance that you need, then he deserves to deal with the consequences. –  Stephen C Jun 28 '11 at 2:27
add comment

About finding a bug: Being an experienced developer, I am not afraid to say to my boss that finding a bug takes between two hours and two weeks so he'd better leave me alone getting work done instead of asking me every five minutes whether I have progressed. I understand that this is not an option to you.

About dealing with your bug: I would go back to the code version (I hope you use version management) when the bug didn't manifest, then change code little by little until the bug appears. In your case, this is difficult if the bug doesn't look deterministic.

share|improve this answer
add comment

The real problem here what details of the bug to tell your boss. By details, I mean the information that he needs to make the decision from his perspective. The details do not necessary have to be of the bug directly. For example, as you mentioned that your boss is not programmer, you could try the following

  • Bad image for the software among the users: something that disrupt the functionality of the product is sure to get bad publicity. Possible solution is to fix the bug.
  • Missed project deadline: spending too much time debugging and analysing the bug due to the lack of experience. Possible Solution is to get more help onto the team.
  • Provide an time estimate on something: You also mentioned that you don't know how long it would take to fix the bug, but you still could mention a range, eg "Look, I don't really know how it would take to fix this bug, I think it will be at least two weeks to even get an estimate.". This also shows that you have some plan on fix the bug.

I don't think that a detailed admission from you of the bug should be a focus of your explaination as it is not productive at this stage. It should be re-examined at the project wrapup stage for lesson learned.

I would only provide the technical details to him if he asks for it, otherwise it may confuse the situation.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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