59

I am a 21-year-old graduate student computer science major, and I am doing an internship this summer at a well-known insurance company as a software developer. Before my current job, I was a research assistant at university, which is a very different environment. I am planning to stay in academia, not industry.

I am one month into the internship now, and so far I was able to find and solve few non-critical errors in the application (the most recent one was yesterday).

The project that I am working on is ending in three weeks, and it took more than two years and few million dollars to get to its current stage.

Over the weekend, I found a very critical error in the application's code that testing teams didn't notice. Fixing the error would require a lot of work, which would delay the project delivery.

I'm facing a serious dilemma,

  1. Telling the team leader or manager that there is a critical error in the system which takes at least a month to fix (in the best case scenario), or stay silent and let the system fail on the first day (or possibly damaging data and waste of money spent already)
  2. I don't know how it can affect my position as an intern
  3. Most of my teammates are contractors, and I am worried my decision will affect them as well.

Please help me make a decision.

Improve this question
1

11 Answers 11

Reset to default
55

"A stitch in time saves nine". It's always better to let the management know up-front about any issues. By doing this, you will in fact help your team rather than jeopardizing the deliverables.

Improve this answer
5
  • Suppose the software gets released with the bug. Sooner or later, word gets out and customers/consumers/clients get MAD. If you report the bug now, the axe won't fall on you because you've done your job of reporting it to your supervisors. If your supervisors decided to release the software with the bug—despite your warnings—then it's their fault, and you tried your best. If you don't mention it, you risk your supervisors getting really mad at your team for not mentioning it earlier—especially if they find out that you in particular knew ahead of time but chose to keep quiet.
    – jvriesem
    Jul 13, 2015 at 17:57
  • 25
    Uh, ok… this answer is correct, but what does it add to the better, more detailed, answer that were already there?
    – o0'.
    Jul 13, 2015 at 23:34
  • 26
    It has a rhyming catchphrase in it, @Lohoris, that has to count for something.
    – user38070
    Jul 14, 2015 at 9:54
  • 4
    @Lohoris While the content is not much different, it's short and to the point - the other answer repeats itself and tries to guilt (Can you look yourself in the mirror?) in a manner that sounds lecturing. (to me, anyway)
    – DoubleDouble
    Jul 14, 2015 at 16:14
  • 1
    I would add that deciding whether or not this bug gets fixed is not your decision to make. Relay the information to your superiors, they make that decision.
    – Premier Bromanov
    Jul 15, 2015 at 18:26
277

You tell your team leader that you may have found a very serious issue. I'm stressing the 'may' because you could be mistaken.

Then it is up to him or his superiors to decide what action to take.

Consider the alternative: what if it is really a critical issue and the software fails after delivery? This could seriously harm the company.
You bet they want you to report stuff that could prevent that!

It is not your decision to determine if/what action needs to be taken, but you should report it, even if it was only for your own integrity: can you look at yourself in the mirror knowing that you failed to report this if it really turns out to be a big issue?

Improve this answer
6
  • 51
    Definite +1, don't use emotive language, don't say "this is a critical bug" - report your findings, let the people who are paid to make decisions make the decision as to what action to take.
    – Carson63000
    Jul 11, 2015 at 22:01
  • 24
    @Carson63000 Agreed. OP: report the bug as a bug. Don't editorialize as to whether the bug is critical. Let management makes its own determination as to whether the bug is critical. It's THEIR product and it's their call to decide what to do with it. In addition. Escalating to management is critical because it is management that sets priorities and deadlines and defines milestones and that has the authority to mobilize the resources needed to deal with the issue.
    – Vietnhi Phuvan
    Jul 12, 2015 at 0:11
  • 21
    If the bug reporting system (either by convention or as an actual UI requirement) invites the reporter to state the severity of the bug, then you should say whatever your best assessment is of whether it's critical or not. Someone who knows better can always change it later, and everyone knows that receiving a "critical" bug report just means the reporter thinks it's critical. It's the same as saying "it may be critical", because nobody takes the word of a bug reporter as meaning they don't need to apply their own intelligence to understand the issue and its significance.
    – Steve Jessop
    Jul 12, 2015 at 11:34
  • 4
    It's your job (same as everyone else) to report bugs that you find. It doesn't sound like it's your job to determine criticality - there will be others more experienced who make that call. There may or may not be good business reasons for releasing as-is and updating with a patch later for this "known-issue". Or the fix may be simpler than you believe. Or you could be correct and it's a show stopper that will take time to fix. Regardless, it's not an ethics question. The sooner those responsible are aware, the sooner the correct decisions can be made to address it.
    – Laconic Droid
    Jul 13, 2015 at 14:04
  • 9
    I like this answer, but I'd specifically add and emphasize that the OP should not attempt to assign the bug a priority, severity, or, most importantly, a time frame to resolve and fix. The conversation should be exactly this much and no more: "I've discovered a possible problem that you should be aware of. When X, Y , and Z happen, A, B, and C will result." The following phrases should not be used: "very critical error" , "testing teams didn't notice" , "lot of work" , "creates a delay" nor should anything about failure, damage, etc. Just the facts, please, and let them decide.
    – Adam Davis
    Jul 13, 2015 at 15:36
50

Jan Doggen's answer is spot on, but something else you can do before informing your supervisor is put together a report on the issue -

  1. Make sure you know exactly where the problem code is
  2. Write down the steps to cause the critical error
  3. Come up with a plan of action to fix the error, even if it's just a rough idea. Supervisors like people who come to them with solutions, not problems.

In doing this, you may find in testing that the error you noticed was already taken care of, or you may find a workaround you hadn't thought of that allows the code to ship as is with a planned patch later, in addition to this being much more useful to your supervisor. You will need to weigh time taken to create this report with leaving your supervisor enough time to make a decision though, so I would recommend spending only a few hours on it at maximum.

Improve this answer
13
  • 75
    You don' t need to know where the critical bug is or how to fix ti to report it.
    – paparazzo
    Jul 11, 2015 at 22:43
  • 10
    I agree with blam. However, these are good steps to take immediately after reporting it.
    – NotMe
    Jul 12, 2015 at 2:03
  • 5
    It's a judgement call. Spend some time researching the defect, but limit that time. Your own understanding of the bug is valuable, but the time the rest of the team is ignorant of it is lost opportunity cost.
    – kojiro
    Jul 12, 2015 at 4:09
  • 16
    "Come up with a plan of action to fix the error" -- personally I would say that if your best guess is that it will take the whole team a month to solve the problem, as in this case, then coming up even with a rough plan of action isn't necessary and probably isn't appropriate. Either you're right, and planning a month of work is way beyond the scope of an intern, or you're wrong and the plan is no use because there's a better way to fix it. It might not do any harm to say "one way to fix it would be...", but it probably won't do much good either.
    – Steve Jessop
    Jul 12, 2015 at 11:41
  • 7
    The project is under time pressure, which means that every hour spent by one man thinking about the problem is one hour that every other teammember remains unaware of the problem. And those are the experienced developers who are almost certainly a lot more productive (no offense but debugging complex problems is a skill not easily taught in class)
    – MSalters
    Jul 13, 2015 at 14:56
36

The existing answers are all quite good, but I think they mostly miss a couple points here & there.

All bugs should be documented and reported to whomever the decision maker for the project is on a reasonable timeline. It doesn't matter how big or small the project is, and it doesn't matter how big or small you think the bug is. At a minimum, any bug should be documented as a known issue at least internally.

Telling the team leader or manager that there is a critical error in system which takes at least a month to fix (in best case scenario), or stay silent and let the system fail on the first day (or possibly damaging data and waste of money spent already)

As a 21-year-old intern, how can you be certain about your "best-case-scenario" assessment? Did you write all of the code that went into the bit with the critical error? Do you know it all inside and out? Do you have access to see all the source code? Is it not impossible that someone who knows better than you might see that this is actually just a simple typo somewhere and it takes a half-hour to fix?

Making time estimates is, in my opinion, one of the hardest things to do in the world of software development. I know I'm personally not very good at it at all (and I need to get better in a hurry--it's a very important skill for my current job). But this is a difficult task for many programmers. And it's not a skill that can be taught. It takes lots of experience, and it takes lots of familiarity with the team. Even if you had a lot of experience, your knowledge of the code base and your familiarity with the team isn't really going to be good enough to even come close to an accurate time estimate. If you're time estimate is correct, it's a lucky guess.

You're probably not really in a position to make an assessment on the timeline to fix the bug. The bigger the team you're on and the less experience you have with the team, the more true this statement is. And this is even more reason for my first point: document & report all bugs. Let the people running the project be in charge of making the decision on what to do with the bug.

I don't know how it can affect my position as an intern

If reporting bugs internally somehow negatively affects your position in the team (regardless of whether or not you're an intern), then this is not a team you want to be on.

There's really no reason to not report a bug internally. And there's certainly no reason to punish those who do report bugs internally. The only way bug reporters should be affected by reporting bugs is that those who are regularly accurately reporting bugs should be rewarded in some way.

So, if worst-case scenario, the company decides to terminate your internship because you internally reported a bug, then you've learned a very important lesson: Never work for that company.

It'd be one thing if you were externally reporting bugs outside the company. Don't do that. That's not your job. But there should be no problem with internally reporting bugs.

Most of my teammates are contractors and I am worried my decision will affect them as well.

There aren't many ways I can see your teammates being negatively impacted by your decision to report a bug other than ways they should be impacted.

  1. If your teammates were lying about/hiding/covering up this bug and that is discovered, they should appropriately be negatively effected.
  2. Depending on how easy it was for you to find the bug, any of your teammates who are responsible for testing may be slightly negatively impacted for not finding the bug (this probably isn't going to be severe unless that person is already on thin-ice).

In the end, I'm not sure how being contractors makes any special circumstance here, other than if you don't report the bug, they may be delivering a product with an undocumented critical error and that's going to make it more difficult for them to get contract work in the future probably.

But ultimately, the short answer is, no bug, no matter how big or how large or how long you suspect it will take to resolve, should go undocumented (internally, at a minimum).

Improve this answer
10
  • 9
    Actually the contractors should be pleased, because they get more days employment if it's a good fat bug.
    – RedSonja
    Jul 13, 2015 at 7:53
  • 6
    I'd like to give you a +100 for "If reporting bugs internally somehow negatively effects your position in the team, then this is not a team you want to be on.", but I can't :(
    – Alexander
    Jul 13, 2015 at 8:19
  • 2
    @RedSonja That's certainly the wrong way to think about it. No one should be particularly pleased in getting a bug report. I know I'm not. It's either a sign I made a mistake or news that I have to fix someone else's mistake. But I'd never hold it against the person who found the mistake. But ultimately, the contractors may not get paid for the extra time it takes to fix the bug (it depends on the terms of the deal).
    – nhgrif
    Jul 13, 2015 at 11:57
  • 1
    @Luaan Most importantly, it could simply be that the bug lies outside the technical specifications for the project. I know at some large companies with in-house programmers, if you're spending time working on something outside what's specified on the spec-docs, you'll be reprimanded--even if it means that delivering the project without spending on that aspect means you're delivering a useless project. It just depends on the team, the project, the contract, etc. And a 21-year-old intern almost certainly doesn't know the details so should simply report the bug.
    – nhgrif
    Jul 13, 2015 at 12:00
  • 2
    Ten years into development and I'm still no better at estimating than when I was an intern. I just way over-estimate so when the project goes over anyway it doesn't look as bad. Honestly, I don't know a single good estimator at any firm I've worked.
    – corsiKa
    Jul 13, 2015 at 22:54
16

Bugs don't go away when you ignore them.

When you report it, there is a chance that a fix or at least a workaround will be found before release, but when there isn't, the software can still get released on time even though everyone knows the bug is present. But the development of a version 1.01 can already be planned and the support team can be warned that there might be complaints.

When you don't report it, the software will definitely get released with the bug. The support team will be completely unprepared and anyone who could fix it might already be allocated elsewhere.

Let me tell you a secret: It happens all the time that a software gets released even though there are still a couple of serious bugs on the bugtracker. That's completely normal in the software business, because it's practically impossible to move a release date which was already announced in advance to your admins, your salespeople, your customers and the whole rest of the world. So just file a bug report as usual.

Improve this answer
3
  • 2
    I can empathise with your "your admins, your salespeople" comment. Probably add "managers who don't understand'.
    – Mark Fitzgerald
    Jul 12, 2015 at 9:18
  • Software gets released with bugs in all the time. That's what release notes are about.
    – RedSonja
    Jul 13, 2015 at 7:54
  • 2
    And sometimes bugs that are known internally aren't necessarily meant to also be known externally... so they don't make it to release notes. For example, any security bug in iOS isn't reported in iOS release notes until the patch that fixes the bug.
    – nhgrif
    Jul 13, 2015 at 12:20
8

If you are afraid to talk to the supervisor, send an email to your colleagues, asking for confirmation that it is a serious bug.

They can then still decide to fix it or go to the manager or ignore it, maybe someone has a smart idea how to fix it too.

Don't worry about it and just report to anyone and let them take care of it. Worst case it is a false alert, best case you saved the company from a huge problem.

And don't worry about deadlines, usually the manager has a lot of buffer planned in and doesn't tell you about it. ;-)

And please, never think about hiding a bug or pretending you didn't see it. You are not doing anyone a favor and sooner or later you will slip and tell someone about it and then hell will break lose. Even if not, you will keep thinking and lose sleep about it, just not worth it.

The natural order is: Report to colleagues, if they ignore it, think about escalating to manager.

Improve this answer
9
  • 10
    And don't worry about deadlines, usually the manager has a lot of buffer planned in and doesn't tell you about it. ;-) This is completely wrong and unprofessional. Flag, evaluate, schedule. Development teams do not need cowboys.
    – Jane S
    Jul 12, 2015 at 21:47
  • 2
    Sending an email to your colleagues rather than your supervisor can be akin to hiding it or pretending you didn't see it, if that's what your colleague decides is the best course of action. The team should have a standard protocol for how to report bugs. The protocol should be the same for every sort of bug, no matter the severity (and actually, at many places, bugs are expected to be reported before the severity of the bug is actually known). Follow that protocol.
    – nhgrif
    Jul 13, 2015 at 12:03
  • If he has to ask here, there is no protocol. And as an intern he might be intimidated by team leader, so talking to the colleagues might help. They will handle the problem however it is handled there. (follow the protocol) If not, it is not the interns fault, but he can still escalate if he thinks they just ignore him.
    – guest
    Jul 13, 2015 at 20:36
  • 2
    @JaneS This is not cowboy behaviour, it just means that a deadline is a virtual date set by a person and if it cannot be reached, then it cannot be reached. Blame is to put on the manager then if he doesn't have sufficient buffer. Seen too many people work themselves to death to meet some random deadline just to see it being pushed for some stupid other reason. A deadline is more like a recommendation or wishlist and reflects the managers abilty to plan risk aware. If there is no buffer, one might say the manager is the cowboy.
    – guest
    Jul 13, 2015 at 20:40
  • 1
    @guest You can't manage what you can't measure. As someone who has both coded and managed many, many projects at different times during my career, it is critical that a manager knows what every member in her team is doing. A deadline isn't set by the manager, it is normally set by stakeholders and investors. If there is a risk of slippage, the manager must manage that risk by notifying the key stakeholders so they can choose to either move the deadline, reduce the scope or increase resources. She cannot do that without her team letting her know what they are doing.
    – Jane S
    Jul 13, 2015 at 20:53
8

The seriousness of a bug is always a bit questionable. Early in my career I noticed that the company's core mathematical library had an error. Initially I thought that this was minor as I wasn't so sure about the math behind this as it might have only been an ordering thing.

Investigating further I was noticed that no matter what mathematical ordering construct I used it would not do anything meaningful. So I asked about this. It turns out they had copied the code from a book and the copy of the book had a typo. In any case I reported the bug and was told that it was not a bug and put this in the backburner.

Then I did a rotation in support and behold there it was again and again. I was a bit confused, clearly they knew of the bug so I inquired further and was told that, yes, it's not a bug, but they were afraid to change it in case something broke!

Three months later another junior developer was walking the hallway looking very unhappy. He told me that he couldn't figure out why his program broke. He checked and rechecked and he couldn't find a bug in his code. I told him that the math library was broken, but he didn't believe me until a week later. He then rewrote a private version of the library to use and behold his code worked. We later discovered that the codebase had at least four copies of the same functions as each developer had made their own version after exhausting other means.

All clients knew the calculation codes were flakey, nobody could possibly use them and every internal programmer suffered. Worse, this library was a big part of the reason to use the software in marketing material.

Was it critical? Hell, yes! Was the bug reported? Yes. But somehow everybody managed to circumvent the bug like nothing had ever happened. Even a serious bug might not mean anything to the software sales and usefulness.

The advice is to report the bug and see what comes out of it. Don't make any strong claims as to how bad it is. Let them decide what to do with it; in the end it's all you can do anyway.

PS: I now suspect that this was one of the places where the copy protection was hidden.

Improve this answer
5

so far I was able to find and solve few non-critical errors

…

I found a very critical error in Application's code

Everything else in the question is irrelevant.

Your job involves finding bugs. You found a bug. Report the bug.

Improve this answer
3

Definitely report the issue. (Although as others have pointed out, don't call it critical unless you know for sure it is.) Where I work, finding a major bug near delivery would make you a hero. You are saving the company and your team a lot of face. I guess where you did your academic research, it's considered rude to point out mistakes. Not in the real world. Mistakes happen, and people will thank you for pointing out their mistakes.

Improve this answer
2

You need to go pick up a copy of the book The Clean Coder. It's not terribly priced.

Take a good read through it, twice even, and I still like to go back and read various sections especially before I take on new opportunities.

The book is written from the perspective of a software engineer that had similar events occur throughout his career. The book is not technical, but explains how to be a true professional and handle engagements with colleagues, deadlines, how to say 'yes' and how to say 'no'.

The book outlines a similar situation you find yourself in and how you should and should not approach it. The book would suggest that you most certainly report it.

As a software developer you are the last line of defense for these things and it is not out of bounds for you to bring these issues up; it's your job. In a professional environment it is understood these things happen. If you're nervous about whether your findings are correct or not get a more senior developer to do a code review with you and see if he can see the same problem.

Improve this answer
1
  • 1
    Thanks; that's much better. I understand the desire to avoid duplication (we could all be better about that...), but we do need to make sure that each individual answer contains an answer to the question. If the end result is the same but the paths there (reasoning, resources used, etc) are different enough, as is the case here, I think that's fine. This isn't a duplicate answer.
    – Monica Cellio
    Jul 15, 2015 at 19:13
0

If this is a critical problem, it's something that will show up immediately on launch. In that case, one question that will be asked sooner or later is "how could we have missed it?", and that will inevitably lead to looking at people working on it.

It's inevitable that people make mistakes, and good software engineering processes are designed to ensure a mistake getting to customers has to have been missed by several people. However this does assume a certain level of competence amongst the people involved.

If it's clear from the version control history that you've been in this code, and the mistake is obvious, and you haven't reported it, then the clear assumption people will make is that you weren't good enough to see it. Fair enough, you're only an intern - but you're trying to impress these people with your skills so that they'll hire you later. If your CV arrives on their desk in a couple of years, do you want them to think "Oh, him. He couldn't see the obvious-and-infamous-bug-which-cost-us-millions problem. Nice guy, but not much good as a coder."?

And as regards your so-called team-mates, you don't owe them anything. For permies, they can't get fired (unless it's actually gross negligence) so it won't hurt them. For contractors, be sure that not a single one of them thinks of themselves as part of a team - they're all working on the clock, that's why they're contractors. And for contractors, if one of them turns out to be incompetent or just plain sloppy, your manager will be very happy to know about it so they don't hire him again, which is a good result as far as the actual team (the permies) are concerned.

Improve this answer
2
  • "For permies, they can't get fired (unless it's actually gross negligence) so it won't hurt them." Being fired isn't the only (potential) negative consequence, so I think suggesting adopting a mentality of "They won't get fired so there's absolutely no harm." is irresponsible. Even if they can't be fired, it can definitely have a negative effect on their career progression within that company. If you're involved in - or even worse directly responsible for - the failure of a major project, that has the possibility of affecting promotions, salary increases, and future project assignments.
    – Anthony Grist
    Jul 15, 2015 at 12:48
  • Permies can easily be fired. Just working on the wrong project (no matter their technical abilities) is enough.
    – Peter Mortensen
    Jul 20, 2015 at 22:24

You must log in to answer this question.

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