16

Example: You're trying to solve a problem, and you can't, try as you might. You've tried every approach you can think of (debugger, Google, forums, etc.) and still haven't been able to solve it. Perhaps the bug randomly disappears on each run and there's no possibility of the bug being related to your use of concurrency techniques. You conclude, then, that the bug only manifests under certain runtime conditions which you are unable to reproduce or isolate.

What do you tell the person to whom you are to report?

Improve this question
3
  • 17
    Can you confirm which question you want to have answered - is it (from the title) "what do I do when I discover e.g. a third party lib has a bug which is confirmed by the vendor" or, from the body of the question "what do I do when my code does not work and I thus fail the deadline". I think both would be legitimate questions, but the answers will probably be different (and maybe you have just picked a very bad example).
    – Eike Pierstorff
    Commented Sep 25, 2015 at 8:07
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – enderland
    Commented Sep 28, 2015 at 13:21
  • Most bosses would prefer to stay updated anyway - so just tell them what's going on. I don't really understand the difficulty here. If it's definitely not in your code they aren't going to hold it against you. (And if they are, then that's another problem altogether!)
    – komodosp
    Commented Oct 19, 2016 at 14:44

11 Answers 11

Reset to default
57

Unless you have proven without doubt that the error is within your compiler tool chain, you should assume it's your mistake. Either in coding or in using the tools of your toolchain.

  • If it is a bug in your tool chain, you need to report it, look for help and workarounds online and find a way around it. Analyse the situation and present a list of possible solutions that are better than what your user is experiencing now. Maybe you can have a version without concurrency. That might be better than having one that randomly crashes. Report all those options to your supervisor and also report that you do not yet know when the original problem will be fixed.

  • Chances are, you cannot prove it's a bug in your tool chain. So you are still looking. Tell you supervisor you are still debugging. Ask him if there is a deadline where it might be better to drop what you are doing and switch to an alternative plan. List all options as above.

Generally speaking, the higher up your report goes, the less interested people are in the details. Your tools are your tools. You are responsible for picking the tools that let you do your job. Failure of your tools will be seen as your failure. That may seem unfair, but try to see it from a different perspective: Suppose you hire a craftsman and he tells you he will be done by Friday with the repairs. Come Friday he tells you that he could not complete his job because one of his tools broke. Would you care or accept that as an excuse? His tools are his responsibility, right?

So as long as your report goes to technical people, mention the problem with the tools and present alternative solutions. If it goes higher up, don't blame the tools. That will only be seen as an excuse. Just present alternative solutions.

Improve this answer
12
  • 12
    Tools do break. And we don't carry backups (or backups of backups in case of double failure) for every single tool. So in reality if this happens, the craftsman tells the truth and there is a conversation about when the tool can be available, what other approaches can be taken, etc. A poor craftsman might avoid the talk, patch it up superficially, meet the deadline and move on, leaving crappy work behind.
    – Michael Durrant
    Commented Sep 25, 2015 at 10:30
  • 20
    @MichaelDurrant That's the same with software developers. Tell your client you didn't make it in time, present alternative solutions. But don't just shrug, point to the tool and blame it. That won't work.
    – nvoigt ♦
    Commented Sep 25, 2015 at 10:31
  • 4
    Or, do what Microsoft does: include a list of "Known Issues" alongside the documentation of the software you sell...
    – Alex
    Commented Sep 25, 2015 at 13:07
  • 14
    "You are responsible for picking the tools that let you do your job." That is not always true; many developers are in a situation where the freedom to choose their own tools is explicitly taken from them. In spite of that fact, I suspect that, "Failure of your tools will be seen as your failure," most likely is true, especially in situations where the developer is not given the freedom to choose their tools.
    – jpmc26
    Commented Sep 25, 2015 at 14:31
  • 4
    +1 for "Unless you have proven without doubt that the error is within your compiler tool chain, you should assume it's your mistake".
    – Eric
    Commented Sep 25, 2015 at 22:30
43

You've tried every solution in your book (debugger, Google, forums, etc.) and still haven't been able to solve it.

No you haven't. You haven't talked to any of your senior team members. You haven't taken any help from your team lead. You haven't considered the fact that if you can not reproduce the bug someone with more experience can reproduce it and assist you in debugging it.

So

Software developers: How do you tell your boss/client that a software bug is responsible for your failure to complete your part of the project?

Just don't. That is just not a real excuse. If a software bug is responsible then discuss that with your employer. You can't tell them I could not upload a 1 GB file quickly because office dial-ups are slow. Instead you should tell them to get you the connection speed you need to get your job done, and then do just that. Get the job done :)

If a team member comes to me and tells me there is this bug that I just can't seem to resolve and it is hard to reproduce I'd be more than willing to help them or at least give them time on it. On the other hand, if they come to me that, no, that can't be resolved because this and this tool is messing it up, I'd really consider it a lame excuse.

It's fine if we can't solve everything on our own, but it's not fine if we don't ask for the team's or a senior's help and just downplay the bug. Dedication to resolving an issue is more important than perfection. Many a times what we consider beyond any explanation is a piece of cake for others.

Improve this answer
1
  • 6
    Your original answer only commented that the OP's assumption that he tried everything was wrong and didn't even mention how to go from here or how to bring it up to management which was his actual question. Your edit now gives a proper answer to that. As for the not nice part, I was merely referring to your very curt dismissal of the OP's point which can sometimes be interpreted as rudeness. It's a good point to make but especially on this site you want to be careful how you word things to avoid having people react too defensively. (Oh, and +1).
    – Lilienthal ♦
    Commented Sep 25, 2015 at 9:07
18

You tell your boss,

I am trying to solve a problem, and I can't, try as I might. I've tried every approach I can think of (debugger, Google, forums, etc.) and still haven't been able to solve it. Perhaps the bug randomly disappears on each run and there's no possibility of the bug being related to my use of concurrency techniques. I conclude, then, that the bug only manifests under certain runtime conditions which I am unable to reproduce or isolate.

That is to say: tell your boss the truth. Personally I don't think anyone should spend more than a day stuck on something without talking to other people in their team (either boss or peers) and giving them the opportunity to provide a useful insight or suggestion. Ideally much less time than that, and I think some people would set a much smaller hard limit (indeed one principle of pair programming is that you should spend zero time stuck on something on your own, ever).

Of this, "there's no possibility of the bug being related to my use of concurrency techniques" is a bold claim, of which the boss (or a more senior tech assigned to deal with this problem that you can't deal with) may require substantial proof. Therefore it's worth assembling this proof in advance, because you've quite possibly reached the conclusion as a result of several disparate investigations. You don't want it to come across as either "I have a hunch that it's not concurrency", or "I have rejected out of hand the possibility it's my use of concurrency, because I am so excellent that I never make mistakes". Other than the boldness of this claim, I don't think anything in what you say is particularly out of the ordinary or should give cause for concern.

Your boss is then responsible for assigning additional time from people better able to understand or fix the problem. As others have said, the extra person doesn't even necessarily need to be any better than you, simply a fresh look can help. Your boss or the team might also decide that since the issue is intermittent, what's needed is more precise logging (or other instrumentation) on a wider variety of environments and data, in the hope of catching the bug occurring more times than you'd be able to alone with your dev environment. Worst case, if the bug lies not in your company's code but in some dependency, you need to prove that and you need to give the third party the best possible chance of reproducing it so that they can fix it and provide an update.

If you don't have a boss then a client would be different. The details of what you've tried are no use to them. If you're self-employed contracting for a client, and you have no boss, and you can't complete the project you've contracted for, then in most cases you can't just ask them to help you fix the problem. You need to tell them there's a delay. But you're going to have to fix or work around the problem yourself, or find someone else who can.

Improve this answer
4
  • 3
    +1 for "Your boss or the team might also decide that since the issue is intermittent, what's needed is more precise logging (or other instrumentation) on a wider variety of environments and data, in the hope of catching the bug occurring more times than you'd be able to alone with your dev environment." Send a instrumented build out to the client. (Although this isn't answering the "how to tell the boss" question, it's a very valid next step.)
    – peterG
    Commented Sep 25, 2015 at 14:12
  • Indeed, managers exist so you can give them the straight dope and they can decide how to present it to stakeholders. Don't lump your boss into the stakeholder category - he's there to help you, not hound you. If he's there to hound you, you probably need a different manager.
    – corsiKa
    Commented Sep 25, 2015 at 15:42
  • Considering that it's impossible to proof a program is bug free (excluding having a complete spec and being able to verify the program against it, which nobody can for a large enough software) all this talk about proof is rather misleading. <insert age old djikstra quote here>
    – Voo
    Commented Sep 25, 2015 at 17:40
  • @Voo: well, I mean an argument that convinces someone of the truth of its proposition. It won't be a proof in the formal mathematical sense. So if you can't bring yourself to call it proof, then what you should make sure you have in order is the information and deductions that tend to support the claimed impossibility of it being your own fault for forgetting to lock something you should have locked ;-)
    – Steve Jessop
    Commented Sep 25, 2015 at 18:52
13

Quite simple - tell them:

It's a random bug which is really hard to reproduce, and I spend x time on it. Now,

  • Do you want me to spend further time on trying to reproduce it, which may take x amount of time or you just don't know at all how long will it take?

  • Work on something more important and come back to it in future (in case more information becomes available).

Stay honest, and don't push yourself too much; it's not YOUR fault. I used to have same feelings as you, but now I keep it simple. The worst that can happen is they will fire you, and maybe then you find a better job... Stay positive.

To be a happy developer, you MUST need to be fearless.

Improve this answer
4
  • Or look for a way to work around it.
    – keshlam
    Commented Sep 25, 2015 at 11:57
  • @keshlam he mentioned in question that bug is really hard to reproduce, i would assume he knows about domain he's working in, and has give up after trying all he could.. telling him to find a way to work around is recursive
    – Mathematics
    Commented Sep 25, 2015 at 12:01
  • also your point is covered in my 2nd bullet point, keep searching till you find a fix or something new :)
    – Mathematics
    Commented Sep 25, 2015 at 12:03
  • 2
    Not necessarily. It sometimes depends on how tightly he's been focused on making a particular solution work. Been there, done that,many times.
    – keshlam
    Commented Sep 25, 2015 at 12:03
8

First rule: If there's a bug, it's because you are doing something wrong. The question is: What are you doing wrong? If you convince yourself that the problem is elsewhere, you are not going to find the problem.

Second rule: Explain the problem to another software developer. You will be amazed how often the plain fact that you have to explain the problem will focus your mind and you find the solution yourself. It's quite typical between experienced developers that one starts explaining a problem and halfway through the process he or she stops because they found the solution.

Third rule: Explain the problem to another software developer. Where you have the subconscious restriction that you don't want to find your own bugs because it means admitting that you made a mistake, the other developer doesn't have that problem and can often easily find a problem that you missed. (Doesn't mean you are stupid - it works in both directions).

Fourth rule: If there is no other developer around, use a cardboard programmer. Just a cardboard cutout of a person, and you explain the problem to that cardboard programmer. You see, in the second case the other developer didn't actually do anything to help you, they just needed to be there. So you might as well explain the problem to the cardboard programmer.

Improve this answer
8
  • 13
    Close. You don't ask a cardboard cutout. You ask the duck. The duck is wise and all-knowing. blog.codinghorror.com/rubber-duck-problem-solving
    – Justin Cave
    Commented Sep 25, 2015 at 8:39
  • Never asked a duck in my life. It was always the cardboard programmer. Especially if there is a programmer - you can't say "mind if I use you as my rubber duck", but you can say "mind if I use you as a cardboard programmer".
    – gnasher729
    Commented Sep 25, 2015 at 15:09
  • 5
    Along these lines, I've found creating a Stack Overflow post helps a lot. I didn't say posting it, just creating it. Forcing yourself to type out the question often leads to the answer. At the very least, you can start to answer it before they do - you look at it like it was someone else's problem. I have posted 83 SO questions in the last 5+ years, but I've probably written over 500.
    – corsiKa
    Commented Sep 25, 2015 at 15:44
  • The rubber duck approach is great. When I was starting out, I used to explain problems to my boss all the time (he used to be a professional bug fixer before a manager). Half the time, before I finished explaining the problem, I would realize a simple solution. The other half, he gave advice that led me to solve it.
    – Brandon
    Commented Sep 25, 2015 at 19:42
  • "If there's a bug, it's because you are doing something wrong." This is true most of the time. It is definitely not true all of the time. Bugs in operating systems, libraries, compiler tool chains, and even the hardware itself (including the processor!) can and do exist. Also, sometimes the documentation for the above things is incorrect. In none of those cases have you necessarily actually done anything wrong.
    – reirab
    Commented Sep 27, 2015 at 0:20
6

the bug only manifests under certain runtime conditions which you are unable to reproduce or isolate

.. so far.

Escalate and appeal for help. All bugs can ultimately be traced through a chain of "at this point I have X when I should have Y. Where did X come from?", it may just be time-consuming. Especially if it is still happening. Oneoff weird events may not leave enough evidence, but if a bug is ongoing then you just need more data capture around it to tell you what's happening.

I've had exactly 3 toolchain bugs in 20 years (Quartus code generation; GCC coredump on particular C++; MSVC2008 structured exception handling on ARM). They're quite rare, and in each case I found a testcase proving that there was a problem in the tool rather than just claiming that it must be there because I couldn't find a bug in my code.

Improve this answer
4

Those are the hardest bugs. When you get towards the end reproducing the bug is often harder than fixing it. Sometimes what you think is environmental is really just a sequence of events that you have not yet identified. Developers will test for how they expect the program to be used and users will do stuff you never expected. Sometimes it is bug that only comes out at production load.

I don't know your environment but do you have a global exception handler that reports the bug details and call stack? That is what we do. Let the user see the ugly error so they can tell you about it. "Sorry you got an error. Please report the following to technical support so the we may address the problem." If the app is connected to a database write the error to the database. Did you write the software up front to deal with and report bugs / exceptions?

I have a serialization error right now that happens only about 1 in 400 runs (and I am not getting a call stack). I am pretty sure it is the framework and not my program but I cannot prove it and it is still my problem. Luckily can just restart the program. It is a known bug that we are tying to fix but decided to release with that bug.

Boss versus client is different.

Boss: Describe the bug and the impact. Are only certain features impacted or is the program as a whole impacted. At this time I am not able to reproduce the bug. Until I can reproduce the bug I cannot fix it. At this point I suspect the bug is environmental. What have you done so far. What do you plan to do. Do you need help. Don't tell your boss you are sure there's no possibility of the bug being related to your use of concurrency techniques unless you can prove it.

Client:
Currently we (say we to the client so feel like a team is working on it) have a known bug. The impact is X. It is a priority bug and we are actively working on it but at this time we don't have a fix date.

Don't go into can't reproduce with the client unless you need their help to reproduce.

If it is the client that reported the bug then you can go into more detail.

Improve this answer
2
  • Something I learned recently: Unit testing. If I can't find a bug, I can just use unit-testing to brute-force the program into giving me the exact output/behavior the bug finder reported.
    – user32190
    Commented Sep 26, 2015 at 0:02
  • OK, did it work?
    – paparazzo
    Commented Sep 26, 2015 at 1:47
3

I've dealt with this a few times. MOST of the time it IS your bug, and you can and should fix it.
Even if it's not, most of the time you can and should be able to work around the problem by rewriting a small portion of your code.
The very few times that seems impossible, someone else on the team might be able to do it (especially if you're one of the more junior members of the team).

In the exceedingly rare case that 1) the problem is NOT caused by your code being faulty AND 2) you can provide verifiable evidence that this is the case AND 3) you can't rewrite your code to work around the problem, then it's time to inform your managers that what they want can't be done without switching toolsets, libraries, whatever is at fault and that that's going to be a major investment, maybe it's better to drop the requirement that exposed the problem until another solution can be found.

But in 20 years in the industry, and years before as a student and hobbyist, I've only encountered that I think twice.
That's not to say I've never run into bugs in compilers, libraries, or tools. But in decades I've only once or twice encountered one where we couldn't work around the bug without an investment that would be higher than the cost of switching to another tool(set).

Admit that you're stumped, ask others to take a look as well (and do so early), and provide what documentation and research you've already done to those people so they don't have to do it all over again.
That's your responsibility as a team member.

Improve this answer
2

A bug is an obstacle. It does not sound like "that's just the way it is" is an option, so the bug needs to be dealt with.

If you don't see yourself making progress on the bug, and if you cannot think of anything else to do, you need to figure out the next option to get a hold on the bug. That might mean external expertise, but more likely internal expertise.

As a "senior software developer", I semi-regularly (namely about once a year or so) have to track down a really bad bug where the final verdict boils down to "code generation error". Which then requires isolating the bug into a reasonably independent example and contacting the compiler writers. Depending on your compiler, this might require some non-cheap support program membership, just to be allowed to report a bug with software you paid for (of course you could also chat up a developer in a bar and slip her a USB drive as long as her management isn't watching: developers rarely see the point of not knowing about bugs).

If you are running out of tools and/or wits, you either need to acquire new tools or wits, or you need to focus on a workaround making the bug not show up for whatever reason.

As an employee, it is your duty to spend company resources, including but not limited to your own work hours, in a responsible manner with a reasonable expectation of return value.

Improve this answer
2

that the bug only manifests under certain runtime conditions which you are unable to reproduce or isolate.

Usually system will behave in a systematic way.When we fail to understand the system everything seems to us random.Yes it'll really hurt if we can't fix/reproduce the bug.Usually not all the bugs need code fix. even simple configuration change can fix the bug.

So We can't approach the randomly reproducible bug in a random way.We have to follow systematic way to corner that random bug.

Note down what are all the scenarios/methods you have followed to reproduce/fix that bug.Ask yourself what else you have missed out or not yet tried out and try them also.If everything fails ask your peers/seniors for help.

What do you tell the person to whom you are to report?

Show your Efforts.

As a software developer you cant simply say i can't fix this bug.

Since you have approached this bug in a systematic way you can show your efforts to your boss.

If you covered 9 out of 10 possible methods somebody else can suggest you that how to try that 10th method. (if you approached in systematic way and documented all cases.)

So you saved your time and also other's time who is looking into this bug to fix the bug or at least it will help to straight away get in to the point to find the root cause of the bug.

Improve this answer
1
  • If it's related to the IDE, chances are it won't be a bug that can never be fixed. Or find an alternative
  • If it's related to the programming language then the same as above, or you could just tell your supervisor and he would understand because he knows the language and its limitations. For example JS is JS, you have to know its flaws before working with it.
  • If it's related to a library you use, if it's open source library, go and talk to the creator, most of the times they are willing to help, if not try to fork or find a fork or an alternative. If it's a closed source then find an alternative. All libraries can be replaced in general, except very few, like a hardware library maintained by only the manufacturer.
  • If it's to a software you're using then switch the software, for instance JDBC driver is published under GPL and we needed GNU license and couldn't find another driver, we started switching to Postgeres, even it will take decades, there's no excuse, if there's an alternative software you must use it and report your reasons
  • If the bug is related to some third party API limitation, then there's nothing you can do, you ask on stackoverflow for help, if they can't help you, you tell your client. A client once asked me to fetch images from a public Instagram hashtag, I asked on SO. Once I was certain that instagram doesn't allow it, I sent him an email and gave him a link to my question with a screenshot from instagram's website, nothing can be done, but prove it to your client.
  • If it's related to a bug I didn't mention that is so important and so hard to fix, and no colleage can help you, then ask on SO, chances are you'll get so many upvotes and if stackoverflow can't solve it, you can use your question to support your claims that this bug is unsolvable.
Improve this answer

You must log in to answer this question.