Admitting Mistakes 1

[CajunCenturion]

We all are human, and naturally, we all make mistakes.

Perhaps an interesting discussion can be had if we each do some soul searching, being honest with ourselves, and discuss, under what conditions you freely admit making an engineering error, and when you keep quite.

What ethical considerations are in play when faced with the decision to be truthful and/or remain quiet?

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[BeckahC]

Interesting thread....

Well.. I rarely make an error that has much impact on the day to day operations of my company... that said, my boss has been pretty foul towards me lately and if I do make a mistake, I would likely go to a co-worker for assistance and try to correct it without my boss ever finding out - if possible.

However, if asked directly - I make it a point to never lie, so I would be completely honest and forthcoming, and apologize for the error and any inconvenience it may have caused.

I suppose what goes through my mind would be something to the effect of:
Is this something that could get me fired?
Is this something that will affect others negatively?
Is this something that I will continue to hear about for years/months to come?
Will confessing to the error make things right/better?
Is there anything that can be done to correct the error so most people will never know an error was made to begin with?
and
How long do I have to correct it before the Sh!t hits the fan?

BeckahC

 

[SF0751]

I would keep quiet if:
1. No one (except myself) noticed the error.
and
2. It had NO impact on any users, operations, etc.

I would tell my manager about the error (after it was corrected) if:
1. No one (except myself) noticed the error.
and
2. It had only minor impact on any users, operations, etc.
If anyone else in the organization had noticed/discovered the error and brought it to my attention, I would notify them when the error was corrected, although perhaps not in the same detail as to my manager.

I would tell my manager about the error (either before or during the correction process) if:
1. Multiple users noticed the error.
and/or
2. It had a less-than-minor impact upon users, operations, etc.
It would be a very quick initial update, along the lines of "This is what happened, this is the impact, and here's what I'm doing about it". To be joined by (after the error has been corrected) with "Here's what I'm going to do to make sure it doesn't happen again".



Susan
^{Don't part with your illusions. When they are gone you may still exist, but you have ceased to live. - Mark Twain}

 

[wbg34]

Good Thread CC

The only time I don't admit to errors is if they are in a test environment and have no effect on the corporate network at all.

I wish I could say that I had always operated like that, but I learned the hard way that it is the best way to do business.

It is too easy for minor errors to snowball into a giant mess and once you get caught in a lie it is almost impossible to regain the trust of those you've lied to.

 

[KornGeek]

When I make errors, if the product has not yet been released, I will generally quietly fix it. Once it's been released, I immediately tell my boss (after thinking through an answer to the inevitable "How did this happen?" question, which I'm also honest about.) and discuss what the impact is, and what can be done about it. If it's a small enough error, unlikely to impact our customers, we may leave it. We may also fix it and issue patches. In one extreme case we actually called the customer and told them to stop using the software until we could fix the problem.

Even if it is a trivial matter, I tell my boss. This is because of the "hit by a bus" reasoning. If I were hit by a bus, how would they be able to pick up where I left off. This may not be the best approach for job security, but I believe that as an employee, it is my responsibility to my employer.

I'm not trying to claim to be a saint or 100% honest, but I believe in fessing up to an error for three primary reasons:
1) As was mentioned above, trying to hide it can snowball into a worse situation (and I've been there).
2) My current boss is much more forgiving to those who admit their mistakes, and not so much towards those who try to hide them.
3) As a parent, I ask my kids to tell the truth, even if they might get in trouble for it. How can I expect them to do this if I'm not willing to?

 

[sleipnir214]

<sarcasm>
Well, it's difficult to say. I don't recall ever having made a mistake.
</sarcasm>

I'm reminded of the joke where a company's newly-hired young executive is at lunch with one of the company's older executives.

Young Exec: Sir, to what do you attribute your success?
Older Exec: Good decisions.
YE: And to what to you attribute your ability to make good decisions?
OE: Experience.
YE: And to what do you attribute your experience?
OE: Bad decisions.


In terms of practicality, I've long found that truthfully owning up to a mistake is the best policy. God help you if you've covered up a mistake and your boss digs up the truth.

The trick is in how you &quot;own up&quot;. From my time in the military, I learned the difference between an excuse and an explanation. When a person gives an excuse, he or she is trying to shift the blame for hte mistake to someone else. When a person gives an explanation, he or she is simply describing how the bad decision that led to the mistake was reasonable one, given what he or she knew at the time.

But some mistakes are unexplainable. For example, when you simply forgot to test that function and that function is what makes the application barf. In those situations, it's best to just tell your boss, &quot;Chief, I screwed up.&quot; and promise you'll not make that mistake again. And you've got to have the fortitude to take a butt-chewing (or worse) gracefully.

In terms of ethics, you have an ethical responsibility to produce the best product you can, whether that product is an operating system or a left-handed smoke shifter. If you do not admit mistakes quickly and fix them, then you have knowingly allowed a flaw in the product to continue to exist. And allowing a flaw to exist is not producing the best product you can.

Now, whether to report an error or not depends on circumstances. If I have a bug in a piece of code on a development server, I simply fix the bug. I'll only report it to anyone if I think that others could make good use of the experience of my mistake. For example, if you implemented a call to an API function according to the interpretation your project team has agreed is correct, but it turns out the team was wrong -- others, in this case, would benefit from your experience.

If the bug makes it into production, the responsibility to report mistakes is greater because others (beyond yourself and your development team) are affected by the bug.


Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[edfair]

If the question comes up, I have no problem admitting it was my mistake.
If the question doesn't come up I have no problem not admitting it unless I want to use it for training.


Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[dwarfthrower]

I make mistakes all the time. Thankfully, being a code monkey, I usually catch them well before anyone else even has a chance to see them, so it's a bit of a non issue.

On the off chance that I don't catch one, then we have a pretty rigorous testing procedure in place which usually prevents the mistake filtering out into userland.

However, what would a net be without holes? Some things slip through, some 'features' that I've coded get released out into the wider world. When they come back to bite us I stick my hand up as technical lead and accept the blame, even for modules that I know I didn't personally write. Sometimes you get a bollocking... usually only from whichever person has taken a bollocking from a customer over the same fault. More often than not everyone realises that no man is an island and software will never be perfect.

_{Never be afraid to share your dreams with the world.
There's nothing the world loves more than the taste of really sweet dreams.}

 

[rosieb]

If I find it myself and there’s no knock – on effect, and it can be fixed quickly. Usually fix it and keep quiet.

If someone else finds it, and it’s minor, fix it and drop my boss an email.

If it’s significant, make absolutely certain my boss hears it from me first, together with what I am doing/plan to do about it.

In purely selfish terms, it’s not worth lying – you usually get caught. A swift acceptance of responsibility and demonstration that you can and will solve the problem, usually goes to your credit. Reasonable managers accept that all of us make mistakes, they just want to be forewarned (always provided that you don’t keep making the same mistake).

A long time ago, I caused the company switchboard to be jammed for 3 days, because I cleared some software after insufficient testing. Fortunately my boss found the whole situation amusing, and our customers were pretty understanding. But I had to endure months of very unsubtle teasing. Taught me about testing and fall-backs.

Ethically, if my mistake is likely to adversely affect someone else, I have to own up. What I really hate is when someone tries to pass the blame on by keeping quiet.

 

[Grenage]

Like most of yourselves, if in the (obviously) unlikely event of me making a mistake I would fix it if I could do so quickly and without causing more issues. I'd mention it if it came up.

If the mistake had larger repercussions I'd let my manager and co-workers know, and request any help (if needed) to get things running smoothly again.

 

[jrbarnett]

I'd do the exact same as Grenage. In fact, I did exactly this last week. I put version 1.1 of my MDB Doc Access documenter addin live on my website and posted an announcement message in the Access VBA forum to tell everyone it was available and the URL to download it from.

Overnight I had a sudden thought &quot;What if...&quot; and the first thing the following day I tested it further and found a bug - wrote a fix and published version 1.1a.
Then I checked Tek-tips and found that somebody else had downloaded it and found another bug, so out went 1.1b.

John

 

[jsteph]

Taking this from a standpoint of a Programmer/Consultant...

We must first define a 'Mistake' as something that is 'in production' and could or has had repercussions. Otherwise--do you run and tell your boss every time you hit 'Compile' and you see 'Syntax Error'?

So I think initially you tell your boss only. Remember--he's responsible for it too, and he'll feel a lot better if he knows and can work with you to either sweep it under the rug or do whatever is needed to fix it. He knows there's no such thing as a programmer who never makes mistakes, and is probably well aware of the 'top ten programmer's excuses' so trying to hide it on your own is a tough road.

An old straw-boss of mine used to say, when you're camping in the woods and a bear comes pawing at your tent door--you're much better off getting out in the open than staying tangled up in your tent as the bear closes in.
--jsteph

 

[Grenage]

Although I'm sure I once read a bear-attack guide that said the best thing to do was stay where you are and curl up in a ball, hoping it gets bored and wanders off to paw at someone else

Anyhow I digress. Not being a programmer myself I define a mistake along the lines of:

1) Implimenting a network policy without thinking it through and rendering workstations and servers useless.
2) Deleting a series of important files because you didn't think they were used anymore.
3) etc, etc...

example 2, assuming the files are backed up you can most likely restore them easily enough. If they were not then someone is going to ask where they went soon enough.

While many of you are programmers, from an network administration point of view these are the kind of errors I could make (although I'd like to think I could never be that foolish).

 

[lionelhill]

Hey, look on the bright side, all those of you who've made mistakes that caused major problems (Rosieb's switchboard etc.) You couldn't have caused a problem in the first place if you hadn't been doing a valuable job. It's those of us whose mistakes don't get noticed because frankly nothing we do is of any great significance to the world who should be worried...

 

[KornGeek]

Interesting how the timing of this thread is. I was working late last night, and I discovered a significant design flaw in the product I was upgrading. This flaw could impact an important customer who is currently using the product.

When I came in this morning, I powered on my computer, then immediately headed to my boss's office to let him know about it and discuss the pros and cons of fixing vs. not fixing it. (In this case, there are significant drawback to applying a fix as well.) Together we weighed the options and decided to implement a fix, but not upgrade the customer until we've had more time to thoroughly test it.

It's never pleasant admitting to a significant mistake before your computer has even finished booting, but I didn't feel comfortable making the decision how to proceed on my own.

The (relatively) good news is that my boss shares a portion of the blame because he was on the test team and gave a thumbs up to the release. That means he missed this as well as I did, so I can avoid the &quot;How did you miss this?&quot; grilling.

 

[Onyxpurr]

Fortunately I too have a very understanding boss. But I also make sure my track record is good enough so that when someone sees my mistakes, they understand it's a fluke and not par for the course.

I will usually tell my boss or customers about a mistake as long as I also make sure to explain my resolution or possible resolutions to the problem. I could never go to my boss and say, &quot;Well I made a problem, but I'll be darned if I know how to fix it. I'm sure people can live with it.&quot;

Although I do know some people that do work that way. :-`

 

[KornGeek]

I remember once going to my boss and telling him that I had made a mistake, and currently had no idea how to fix it. We worked together to figure out an idea, and then Tek-Tips helped me figure out how to implement it.

Unfortunately, my track record is not the greatest, but I have virtually no testers on most projects, and I have explained that only having one point of view testing the software is asking for problems. When the budget isn't so tight, we might get one or two people in here to help.

 

[jsteph]

With software so complex, live, real-world testing is everything.

Sure we can bench test, but how can one possibly code for every possible move the user might (will) make in your first draft. You've got to give the rough draft your best shot and then let the testers find your mistakes. Because the mistakes are always there, waiting to be found.

I managed a 2.5-year banking software project and we looked at Mercury, and a few other 'automated' testing packages. At about $150,000 for these things, plus the learning curve and scripting development, we said &quot;no way&quot;. We instead hired 2 people to play teller, accountant, and auditor full time every day for most of the project--once the initial code started taking shape.

I believe they were so much better than any 'automated' package could have ever been, and I attribute the success of the project in large part to their thouroughness. It became a game to them to make it crash, find bad data, etc, etc. I'd find them doing stuff like purposefully kicking the cord out of the workstation in the middle of a transaction--it's virtually impossible to automate that exact situation.

Bottom line: Nobody can write code from start to finish without some mistake somewhere, so the 3 most important parts of the project are: Testing, Testing, and Testing.
--jsteph

 

[rosieb]

There is a difference between a mistake and a wrong decision – it is often worse to make no decision than to make the wrong decision.

Decisions have to be based on current knowledge, and a wrong decision is one that can be seen to be wrong, but only with the benefit of hindsight.

A mistake is an action which, given the current state of knowledge, is wrong.

In a development environment, mistakes are bound to happen (unless of course, like sleipnir214, you are perfect), that is the purpose of the test phase. A developer should test code thoroughly, but they cannot be expected to pick up everything. If something slips into production, the primary responsibility lies with the tester(s), who should not be the developer(s). (Though if a bug report from testing runs too long, the developer(s) should be taken out and shot! – I’ve produced bug reports longer than the upgrade spec, and my upgrade specs were very detailed.)

<aside> jsteph We tried automated testing, complete waste of time & money. That, and scripted testing, only pick up the obvious stuff, the real results always came when we got into the competitive “see who can break it first” routine.</aside>

In a production environment, if you make a mistake (delete files, change settings, release insufficiently tested software, etc.) you must accept the blame. Most managers understand about learning from experience, the important thing is to be seen to learn, and not to make the same mistake twice.

 

[lionelhill]

I work in a scientific environment, but I am not a trained data analyst, and my programming has grown out of a hobby. Nevertheless data-handling stuff I've written has ended up being used by people I don't even know.

It scares me to death that mistakes I make will end up reflected in other people's publications. But there is no screening for my work, no one testing it, and no one else who understands the potential problems of home-grown code. If the graphic interface looks right, people assume the data are right, and no matter how hard you tell people: &quot;check your data! Make sure the calculations are coming out reasonable!&quot; no one ever does. Half the time I'm having to read a file format from some instrument whose manufacturer isn't being very translucent, so even my guessed file formats are hardly professional.

I'd be interested if anyone has any advice on how to quality control in a one-man-band situation like this. It is doubly awkward that computer work is largely seen as &quot;playing&quot; and therefore if I'm trying to concentrate on where my pointers are pointing, everyone regards me as fair game for a discussion on the relative merits of IDS and Tony Blair. Ohje and yuk.

We share-ware-on-the-side people still have a responsibility not to make gross mistakes, and to get methods to find them when we do (inevitably) make them.