How should I handle multiple mistakes without losing credibility?

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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."

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.