42

In short: I've made multiple mistakes in a calculation software within a year. These mistakes caused no harm whatsoever, but I'm afraid that I will lose credibility if I approach this the wrong way. I would really appreciate some advice on this issue, since this is my first job out of university.

The details: Since about two years I'm working in a larger company (about 100-200 people). Within the company I'm working in a subgroup of about 5 people. I'm solely responsible for maintenance and bug fixing of a 10 year old software (which is a huge mess). This software is used to compute safety margins on our products (e.g. calculating that a chair will hold up to 100kg). Last year someone reported a bug that some of the numbers calculated by the program were not adding up. I found the problem and it turns out, that the person was right. However, this was not an issue, since the problem was working in our favor (in the chair example, the allowed weight would be 105kg instead of 100kg). So no harm done, neither for the customer, nor for us. I presented this fix (among other things) during our yearly company wide internal update conference. So far, so good.

Today, I started to write a detailed report about the product we sold last year and took a closer look at the numbers. I noticed that something seemed slightly off, so I took a another deep dive into the program and found that the same bug, which caused the issues last year, was still present in a different part of the code and still caused the numbers to be slightly wrong (chair will hold 107kg would now be the correct result). Again, this causes no harm or problems for the company. However, different parts of the company rely on the calculated numbers and I will have to give a company wide update on the issue.

Now I'm afraid that this could cause my coworkers and the company to lose trust in me, the software package and the provided numbers. I'm not worried about losing my job, just about the credibility of my work. How would you approach this topic? Which point would you stress in the company wide update?

  • 75
    I am confused by the question. You say that you are responsible for bug fixing. You're fixing bugs, and proactively looking for similar bugs when you fix them. You're doing exactly what it is you say you're being paid to do, so what is the specific problem that needs to be solved here? – Eric Lippert Jan 23 at 23:07
  • 3
    @EricLippert In my understanding; op was tasked with fixing a bug which he did, but failed to notice that he only partially fixed it (it still exists in another part of the code) so he's worried about having to update everyone as they will think he didn't fix it properly the first time. – Aequitas Jan 23 at 23:31
  • 6
    Did you write the code with the calculation errors, or did they exist prior to your working there? – Daniel R. Collins Jan 24 at 0:23
  • 7
    I agree with Eric Lippert's point of view but I also want to ask, do you have an automated test suite for your software? If not, that's a good place to start because now you can show that you are actively taking steps to avoid mistakes (i.e. by finding bugs as they get introduced or by being able to discover existing bugs in a more formal manner) and that can go a long way towards showing that you really are being conscientious :) – A Regular joe Jan 24 at 10:26
  • 2
    Aequitas is correct here. I fixed the bug last year, but failed to realize that the same faulty code was used in a different part of the software. So it feels like its my responsibility and my mistake, even dough I didn't write the faulty code in the first place. @Steve: I am sure, that it was not underestimating by design. It's the kind of bug, where if you use a very specific but common set of input values a loop does not terminate the way it should and the output value is simply wrong (its written in LabView btw) – cryptgen Jan 24 at 10:52

12 Answers 12

111

I do not see a problem here.

  • You found a bug, [100~105 case] reported it and provided the fix.
  • After some time, you found another bug [105~107 one] (and probably the way to fix it, too).

One can say, it should have been caught earlier, but nevertheless, you are the one who actually found this bug out and providing a solution. Until and unless you are solely responsible for carrying out the QA on this whole application [*] and ensuring the correctness - I'd say this is something extra you have done over and above your assigned tasks.

Go ahead, publish the update same way you did last time.

As metioned in the other brilliant answer by Richard U,

You don't lose credibility by admitting (your) mistakes, you lose it by trying to hide them.


[*] - Maintainance and bugfixing is not exactly the QA (finding the bugs).

| improve this answer | |
  • 3
    @Chris OK, I never asked OP to claim they went over and above, i was suggesting that they have nothing to be ashamed of / hide. The fact that they discovered the bug and are going to fix it, is extra, not less. Obviously, nothing to brag about, but neither to be sorry. – Sourav Ghosh Jan 23 at 16:49
  • 5
    +1 just for "You don't lose credibility by admitting (your) mistakes, you lose it by trying to hide them.". I really spend too much time explaining this to my coworkers... – LP154 Jan 24 at 13:28
  • 3
    @LP154 Thanks, if that's the reason for UV, please consider repeating the act on the other answer by Richard - I stole his words. – Sourav Ghosh Jan 24 at 13:43
  • "You don't lose credibility by admitting (your) mistakes, you lose it by trying to hide them." - Only if you fail :) – Ant P Jan 24 at 16:12
  • "over and above your assigned tasks" - that's the part I'd be concerned about. Is that what the employee is supposed to be doing with their time? – Mazura Jan 25 at 1:43
76

You don't lose credibility by admitting your mistakes, you lose it by trying to hide them.

In your particular case, your calculator was conservative in calculating weight tolerance, which only increases the margin of safety, so as you said, no harm done.

The fact that you spotted the error yourself, and corrected your error is something to be proud of, not ashamed.

Hey. I found a bug, and fixed it. No harm done to us or our reputation.

I'd have much more confidence in that than the person who finds a mistake, and either ignores it, or quietly fixes it, hoping nobody would notice.

Pointing out and fixing your own mistakes means you can be trusted, and THAT, more than anything else demonstrates your credibility.

| improve this answer | |
  • I upvoted as well, but I dislike the second sentence a little. I don't think it matters that the calculator was "conservative" - it was conservative purely by luck, and the error could very well be in the other direction. I don't think any attention should be brought to the exact direction of the error (except in technical discussions where it has to be taken in account for some corrections). – Džuris Jan 23 at 23:55
  • 3
    @Džuris The direction of the error determines whether or not damage was done – Old_Lamplighter Jan 24 at 2:32
  • 4
    Exactly this. If you want even more bonus points, come up with techniques to prevent/reduce such scenarios in the future- unit tests, integration tests, code reviews, increase the number of code reviewers on tricky parts, etc. – Gabe Sechan Jan 24 at 5:24
  • 1
    As I said for Sourav's answer : +1 just for "You don't lose credibility by admitting (your) mistakes, you lose it by trying to hide them.". I really spend too much time explaining this to my coworkers... – LP154 Jan 24 at 14:54
  • 1
    @RichardSaysReinstateMonica a good engineer gets the math right so they know how conservative they’re being. – candied_orange Jan 29 at 14:48
18

As others have said, it seems like you've found a pre-existing bug and fixed it. I'd be delighted if a member of my team did this.

For extra credit, try to figure out how you can change your process to stop this type of thing from slipping through the net in the future:

  • Do you have unit tests? What are your code coverage stats like? Is there a test covering this scenario. Consider suggesting a concerted effort to retro-fit unit tests where they should already exist and to ensure there are sufficient unit tests for all new code.
  • What is your bug fixing process like? I always like to start by writing a unit test mirroring the conditions which cause the issue to manifest itself. This will fail until the bug fix is implemented. Then, the unit test is in your code base if it is ever tripped again, you will know.
  • My team's definition of done contains a Unit Test Review. This is where another member of the team (mostly a QA - but it could be anybody) reviews the unit tests written for a ticket to ensure there is at least one test for all possible scenarios.
  • Is there a problem with the QA process? What could be changed there? Are the requirements (or Acceptance Criteria) detailed enough?
| improve this answer | |
  • 1
    Also, look for opportunities to reduce duplication in the code, so if you fix a bug in one place, there isn't another place with nearly identical code and nearly identical bugs. – Karl Bielefeldt Jan 24 at 3:19
  • 1
    Ditto here: There's a lack of testing that you can work to remedy. Approaching it as "I'd like to dedicate 30% of my time towards a code review and establishing some solid test cases we can run through the software. Are there other engineers that can assist in validating parameters to use for my test cases?". Proactive fixing of issues and adding validation are all huge BONUS opportunities for people. I'd love someone doing that on my team- assuming I didn't have some other deadline. – J.Hirsch Jan 24 at 13:55
11

Speaking as a software developer with over 7 years of professional experience, +25 years total programming experience, and several years in college learning situations, making errors is common and generally don't reduce your reputation.

Every software developer in the world has made mistakes. Linus Torvalds, the originator of Linux, makes mistakes. Engineers at Apple, Google, and Microsoft make mistakes. Literally everyone who writes software makes mistakes. If they didn't, all software would be 100% secure, work perfectly, and never need updates, except for adding new functionality.

There are specific times that your reputation becomes damaged, though. As someone else mentioned, hiding your mistakes is a big problem. Also, blaming your mistakes on others is a problem, unless you can actually prove it was that someone else (which is usually petty anyway, unless you are going to get fired for the problem caused). Even if you routinely make mistakes, this is your first job and you only have a couple years of experience. You are still learning and expected to make mistakes. As long as you learn from the mistakes, you're generally fine. If you keep making the same mistakes, then it becomes a problem. But the fact that you found and most importantly fixed the same error elsewhere shows that you are learning from your mistakes.

Those errors should likely have been caught by QA. Since they weren't, they were likely either hard to find or your QA department is lacking. The fact that the same error wasn't noticed in the software for a year after knowing about the first issue shows that it's not an easy bug to find. Suggesting improvements to the processes will increase your reputation, not reduce it.

Keep learning, keep striving to better yourself, but realize that because you're human, you're going to make mistakes. There are ways to help self correct, such as unit testing, automated testing, and other testing options, so make sure you are using them appropriately. As long as you are making an honest effort and your manager & team know this, you should be fine.

| improve this answer | |
  • Yeah, QA is kind of an issue here. The software was developed by two guys about 10 years ago, both of which left since then. However, they were trusted in the company, the software itself is huge and written in LabView, so basically, no one in QA wants to touch that thing. The calculations, which went into the program where checked and the results are checked for "consistency". I'm the only one looking at the code itself. I really should think about a way to ask my supervisor for a way to get some QA going here, even if only for bits and chunks of the program. – cryptgen Jan 24 at 11:02
  • @cryptgen, it's great those guys were trusted, but there's a very real concept called "trust, but verify" that is extremely important in software development, as I'm sure you either already know or are learning. QA definitely needs to be brought in on this project, whether they like it or not. And when they get brought on, there's likely going to be a greater need for developer time on it, since it'll likely have a significant amount of bugs found. Most software does, especially when QA has never touched it. – computercarguy Jan 24 at 17:00
9

Say something like "Remember that bug that I fixed x months ago? Well, I discovered a similar bug in other parts of our code base. This bug was working in our favor, so no one has been hurt by it. However, a bug is a bug, so I'll be rolling out a fix shortly."

| improve this answer | |
  • On a side note, 100-200 employees is a mid-sized company. – bobsbeenjamin Jan 31 at 16:58
8

So, you are finding and correcting mistakes in code that was written 10 years ago, ie 8 years prior to you joining the company.

These are not your fault.

So, just report the corrections so that all can be aware of them. One point does come to mind - there could be other parts of the code that now report incorrect values as the "tolerance" from those errors you corrected has been reduced.

| improve this answer | |
  • 1
    Even if OP had written the mistakes: Everyone makes mistakes, that’s why we have unit tests, integration tests etc. etc. A good company culture doesn’t blame people for making mistakes but tries to find out why they happen and how to avoid them. – Michael Jan 24 at 11:33
  • @Michael I understand that and that point has been so well-covered in the other answers that I did not feel a 3rd repetition of that point was valuable. What i did feel valuable was pointing out the timeline which was not so well covered. – Solar Mike Jan 24 at 15:55
5

I'm going to post the semi-mean answer: you're on-base. Your coworkers are going to lose at least a little bit of faith in your numbers. It's only natural - you said X is 100, and it turned out it wasn't true. You said Y is 210, but it was actually 224. So now when you say Z is 70, they're going to wonder a bit... is it actually 70?

That said? Don't make a mountain out of a molehill. This happens. To everyone. And the absolute precision of the numbers themselves may be weighing on your mind a lot more than it's weighing on theirs.

The way you should address it is: don't make a big deal about it, and focus on letting the accuracy of your work going forward help reestablish the faith that your numbers are correct. The only way they're going to return to trusting "Z is 70" is if you establish a history going forward of delivering accurate numbers.

| improve this answer | |
  • 2
    Yes, it only takes a few bugs in rapid succession before I start to hear things like, "Let's make sure we give extra time to integrate X as it is fairly unreliable." or "We'd better double check those numbers." You can beef up the time you spend on testing. You can also do certificate based checks. Let algorithm X come up with an answer. Then verify the answer with algorithm Y (verifying an answer is often easier than coming up with one). If the two approaches don't agree report an error rather than reporting the wrong answer. We do this when we do math in our head all the time. – Pace Jan 24 at 1:32
2

Writing a separate answer because I want to address one point in the OP's question (and that was echoed in some of the responses).

Unless your system was deliberately designed such that errors always caused "conservatism" and therefore increased the margin of safety, all bugs, regardless if they increased or decreased safety are equally as important.

When doing any sort of analysis on frequency of bugs, etc., you shouldn't pay too much attention to how devastating they were, but rather how devastating they could be: just because you've gotten lucky, doesn't mean you'll be lucky the next time.

| improve this answer | |
2

happens all the time, it doesn't matter, relax!

what you should do for yourself:

  • figure out if that bug was already there when you took over the software or if you introduced it while working on other stuff. if it was you, think about how to avoid that in the future.

  • if the system is gonna live a few years, think about writing a lot of unit tests that capture the current state, so you can see when new changes break something. make sure the tests you write are sane and maybe you will find a few more bugs to fix as a bonus.

| improve this answer | |
2

If it’s merely a matter of two errors (“multiple” sounds a lot worse, eh?) then acknowledging it is better than risking being viewed as someone who hides things.

But it also depends on the development culture. I could argue it as three errors: a calculation error, then a failure to check for the same error elsewhere, and finally (if it is indeed the same error), repeating code in two places instead of calling one bit of code from both places.

A proverb in both technical writing and in software is that “identical” things a tendency to become non-identical in a way that proves Murphy correct.

| improve this answer | |
1

As others have noted, this won't hurt you.

But what will really make you win is coming up with a QA system to find all the calculation errors. Meaning software testing: software that checks the software by flinging it a range of known input sets with known answers, and making sure computations are correct. This was never done; that's why those errors were allowed to linger. This could be a major feather in your cap.

Note that you should do this if a career in QA appeals. You could end up doing it a lot.

| improve this answer | |
0

Agree with all of the previous - not your fault, you're doing what you're supposed to be doing, you're finding and fixing other people's old mistakes, etc.

My two cents worth to add is, I would bring up in a meeting on the issue, that since you found TWO mistakes in the old code, you are now suspicious of the whole package, and you would like to conduct a thorough analysis of the entire program. Propose how you would do this work, and what tests you would conduct to ensure to your own satisfaction that the code is now properly debugged. There may well be even more mistakes -still- lurking in the code, and your concern over repeatedly announcing a program to be fixed, and subsequently having to announce that it wasn't fixed after all are quite legitimate. Too much of that DOES undermine your credibility.

Make a point of saying that you can fix individual problems just fine, but in view of what you have seen in the code, you cannot vouch for the correctness of the entire package, unless you are given an opportunity to go through it thoroughly. Needless to say, I hope, if you ARE given such an opportunity, you'd damn well better make sure you get it right. Seriously exhaustive tests, have someone else (preferably several someone elses) go over it with you, have other people design their own, independent tests and verify the output, etc.

Depends on how important this software is to the company. If it's important, and you do can a good job of bringing it up to modern standards, such that everyone can be confident in what it produces, this 'problem' could actually be a great opportunity to show how valuable you can be to the company.

| improve this answer | |

You must log in to answer this question.

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