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

 

[CajunCenturion]

The first thing I would do, lionelhill, is to professionalize your activities. It's hard to blame people for viewing computer work as "playing" when you refer to yourself as a "share-ware-on-the-side" person, and your production as "home-grown" code.

If you are not doing so already, I would apply the tried and true principles of software enginneering to your projects, including proper documentation. Specifically, in your case, that would mean performing a requirements analysis that would include meeting with the appropriate scientists and getting down in black and white, the mathematical formulae pertitinent to the research, with special attention being made to the end-cases. Then upon implementation of the algorithms, hand checking, again paying special attention to the end-cases.

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

 

[GwydionM]

Admitting errors depends on whether or not your managers take a sensible attitude, and whether other people will mostly admit them.

I think that British and American law sets a bad example, encouraging people to deny errors for the legal advantage it gives them.

 

[lionelhill]

Thanks Cajun. I've evolved a habit of keeping anotated printouts of all my stuff at every point where I let a new version out on the world, mostly for self-preservation when something goes wrong. Also I do take test files and check that data I read from them are identical to those read from the instrument. But I'm always a bit scared that maybe there is something funny about the handful of test files I use that means they are calculated correctly while others aren't.

I'm not sure what you mean by end-cases?

The time has definitely come, and I will try to professionalise. Do you have any recommendations for learning this side of things? Us hobby people tend to get quite good at linked lists and browsing endless books on our favourite languages and computational problems, but the management of software projects isn't our strong point... The contrast between the ISO9001 statements attached to the commercial software (perfect except it doesn't do what I/we need) and my rather wobbly testing (sort of does what I/we need, but does it do it right?) is alarming.

On a lighter note, it is amazing how long errors can exist and not be detected. I wrote a thing for analysing data from Kontron spectrophotometers that was in use for nearly two years before someone found that if you stopped the instrument while a sample was being measured, my program couldn't handle the half-written data file. It just hadn't occured to me that someone would stop the machine in mid measurement... A useful lesson, fortunately not a data-sensitive issue.

 

[CajunCenturion]

By "end case" I mean the following. In many mathematical formulae, there are situations where normal rules don't apply. For example, a formula that works on a series from 0 to n. If a division is involved, the "end case" is dealing with that one exception where you have a divide by zero condition. In other words, special handling is needed at the front end of the series. Another example is where the results of some formula are asymtotic, and you need to impart special rules towards the back end as rush towards that end. And sometimes, you can have a singularity in the middle. I remember one case were the basic formula was outputting a sine wave, but because of a phase shift, the first derivative was undefined at the point of the shift, so special code had to be in place to handle that one point. These types of exceptions are generally grouped together as the "end cases". It may be that in some of your research, or the research that you're supporting, such end cases exist, and if not handled properly, that's where programs fail.

There are lots of resources about software engineering practices. Without going into too much detail, they involve careful adherance to the software life cycle phases, including Analysis, Design, Implementation, Testing, Rollout, and Support. Complete each stage in order, backtracking as required, with proper documentation and as much user-involvement as you can get or stand. It's not necessarily a straight-line process and you may need make adjustments, and go back to a previous stage during the process. You don't start building a building by pouring concrete and laying bricks. You start by analysing the purpose and needs of the building, drawing up plans, revising the plans, and reviewing them with the customer, revising again, playing what-ifs (a cat 5 hurricane, or a level 8 earthquake), then revising the plans and reviewing until you think all the bases are covered, and all before you pour the first ounce of concrete. The same should be done before you write your first line of code. When you start writing the code, it's like pouring the concrete. You should completely understand what you're building before you start.

Granted, we don't live in a perfect world, and forces that we have no control over (the boss, the bean counter, the markets, and so forth) try to rush things along, and short-circuit the process. As professional software engineers, we need to approach the project, and these peoples from the perspective of a professional enginneer and do the job right. Not easy, and not always possible, but it's what we should studiously stive towards.

We can't expect other to take us seriously and treat us professionally unless we treat ourselves and approach our task from a professional perspective.

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

 

[CajunCenturion]

Oh yeah, and we do make mistakes, deal with them professionally as many before in this thread have already expressed.

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

 

[lionelhill]

Thanks. I've found this thread helpful and interesting reading. Yes, I think if I worked a bit on following a more careful cycle like that, and writing down which bit of it I'm in at the moment, it would be easier to muster more interest in the creation of a valid product. People like the result, but do tend to regard time spent getting there as time wasted playing with computers. I also agree that if (time saved by product) < (product development time), then there wasn't any point! But nevertheless, product has to be safe to use.

Going back to the original subject of the thread, I think it's vital to admit errors that have an impact on others as soon as possible. But personally I find it hard to do, when you know there are people out there whose attitude will be &quot;there, well that's what comes of meddling with something you don't understand!&quot;

 

[skiflyer]

if ((time saved by product) < (product development time)) {
waste of time
}

Maaaaaaaaaaybe but, I tend to think it's more complicated... properly written programs can increase confidence in results, allow time to be streamlined... allow more permutations... basically, not just save time, but actually open whole new routes, often ones that people didn't even think they wanted in the first place.

-Rob

 

[TomKane]

I can hold my hands up when I've made a mistake, but the way things are where I work is that a lot of things are up for debate - sometimes &quot;the system&quot; gets blamed when something is done wrong but then we do a bit of digging and find that the system worked OK but the user &quot;got it wrong&quot; -but maybe the software, while doing what it was designed to do, wasn't intuitive enough? Or maybe more time should have been spent making sure the user was happy in what they were expected to do? Yes a mistake was made, but who made it?

We recently had a situation where we took on a function of another branch and a lot of the data was put into the system correctly from the point of view that the data was entered and the system processed the data as entered, unfortunately the data that was given for the users to input was inaccurate. So when the end result comes out in the form of a report or invoice there's a lot of &quot;this is wrong, but I input the data right - the system must be wrong&quot; and then you end up examining the systems to see what has happened only to find the problem was at source. Funnily enough, that can be a hugh relief to us IT guys but unfortunately the users then have a lot of correcting to do and are probably cursing every keystroke.

I used to have a thing about hiding other people's mistakes - I've never been very fond of the &quot;whistle blower&quot; mentality and while I've not been afraid to admit my own failings (where absolutely necessary) I've had real trouble admitting other people's - this has on occasion meant that I've worked weekends trying to get other people's work (while they're off on their holidays) on an even keel and try to get my own stuff done as well. I saw it as &quot;taking one&quot; for the good of the team.

I've recently got out of that habit (a bit) as unfortunately the effort wasn't appreciated by my co-worker in fact quite the opposite - I became something of a pariah. Clearly by correcting someone else's work in order to spare their blushes in front of users/management is just plain wrong and I deserve everthing I get. I went through a short period of &quot;whistle blowing&quot; and took no pleasure in it AND it only threw petrol on the fire...

 

[jrbarnett]

Going off on a tangent slightly, but still highly relevant to this discussion, I have just come across a situation where a piece of third party software I was using to validate the output of a program of mine didn't correctly verify its output.

So, at the risk of opening a new can of worms, who is to blame when an automated testing tool that the developer relies upon to give accurate results, especially if it comes from a well respected organisation within their area of operation, passes as OK data that certainly is not?

I would be very interested to hear what people think on this.

John

 

[edfair]

The developer who is using a defective piece of software shares responsibility with the originator of the defective software. Sounds like your company is doing some beta testing by accident.
In a life support situation where somebody dies both are going to pay the price.
So, who tested the test suite? And how rigerous was the testing?

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

 

[jsteph]

<<beta testing by accident>>
Been there, done that. It's a pisser, it's all too common, and I think it's more 'on purpose', from the software company's point of view--they know they've rushed it out, they can't afford (either in terms of time-to-market or manpower) to test it themselves, so they let the unsuspecting customers do it. And the resonse is always 'oops, how could we have let that get by us?'
--jsteph

 

[jrbarnett]

The trouble is, in my case, the developer of the validation tool is the organisation that defined the standard that this is supposed to validate.
I only picked up on it when I found a second tool by accident on a web search that claimed this tool had flaws, so ran it against my test routines.

John

 

[edfair]

Don't you hate that sinking feeling in your stomach when you find out you've been lied to?
I just naturally distrust things from companies/organizations that define the problem, then define the solution. You are at the mercy of possible incompetents. In your case, verifiable ones.

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

 

[Georgi1chuikov]

I am in a situation where I am the final QA tester for a product release that influences my entire companies buisiness. If my product is messed up, my company stops. However, sometimes when the 20th version of the software is placed on your desk 2 hours after normal quitting time with a bare minimum of 4 hours of intensive testing needed (even though we prefer 5 work days) it is easy to overlook the non-mission critical errors if the deadline is 8 the next morning. Conversly if my !@#$ing programmers would come clean with there own errors (&quot;Oh yah, we knew about that but did not think it would be a problem....&quotI would not have to burn the midnight oil hoping we do not find other errors. When a designer/programmer is not completly honest with his self critisism it can be a real pain in the A for the others of us that are responsible for the perfection and release of the final product. Also, isn't it fun that the marketing department can sign off on a product they never touched, have the release happen with a ludicrously small amount of testing because of artificial marketing needs, THEN blame me when it breaks in the field!! oh well. nothing new here.

 

[edfair]

Just in time programming? Why not just go ahead and slice your wrists?

Marketing is like that. No telling what they would be selling if they didn't get this job.

 

[Georgi1chuikov]

LOL .... JIT programming. Thanx for the new acronym edfair
Our marketing reps are picked by the size of their ....uh.... well, these ladies are gifted, just not technically. 8
Unfortunatly in my company they call the shots on IT deadlines. Yes, I am looking around. I bet an entirely new thread can be made about marketing vs. IT, in every company I have been in this has been an issue.

 

[Onyxpurr]

Yes, TomKane, I feel your hurt.

Quite often is my responsibility as the analyst/programmer to determine if the output that the user has identified is really the output they want.

Quite often I've had users tell me it's my fault that the report they requested is wrong because of the faulty description they gave me. (&quot;Oh wait, that report shouldn't have x in it!&quot; - &quot;Well, duh, you didn't say to exclude it!&quot

 

[SQLSister]

JIT programming, Ah now I have a name for what we do here! Also I see that marketing people are the same everywhere too!! And here I didn;t even realize I have the...Uh... assets to be in marketing. Some of us prefer to use our brains!

Weighing in on the honesty issue. I can;t say I'm perfect. If I find a problem that no one else knows about and I can fix it before anyone else will figure out there is a problem, I will quietly fix it and make a note to myself not to do that particular stupid thing again.

However, if there is any chance it will be found out or if it was reported by someone else, I own up to it. I try to never to tell my boss about a mistake without at least a plan for how I'm going to fix the problem or determine how to fix the problem. This makes bosses much more receptive to you admitting a mistake in the first place.

Sometimes I'll own up even if no one has figured it out because it was a major problem and will affect the company bottom line even if they don't know it yet. I once underbid a project by $600,000 due to a mistake in a my spreadsheet. No one else would have caught the error for probably several years (plenty of time for me to have found a new job if I was the dishonest type) but we would have lost lots of money on the job if we had won it without making some major adjustments. I told my boss and the CEO as soon as I realized even though I thought I might get fired just because it would be wrong to conceal the information that down the road could cause a lot of people to lose their jobs. And I went in with a plan for how we could minimize the amount of money the company lost if we had won the bid.

It's my experience that most bosses prefer to know and not be blindsided by the customer finding the problem later.

It's also my experience that some people can make all the mistakes in the world and they are so good at passing the blame that they are never caught. I have a friend who refers to the woman at her office who does this as the teflon blonde because nothing ever sticks to her. We have a teflon person here, too, but the word I use to further describe her is not a nice as blonde (but it does begin with a b!). It is very frustrating to people who own up to their mistakes to work with someone who management perceives as perfect because nothing is ever her fault.

 

[arlems]

SQLSister: JUST A FEW GOOD MEN. YOUR APPROACH IS GOOD. BETTER TO GET THE THING OFF THAN KEEPING IT FOR YOU AND FEEL GUILTY AND TERRIBLE ABOUT IT FOR THE REST OF YOUR LIFE. PROPOSING A SOLUTION WITH YOUR MISTAKE IS THE TIP BECAUSE IT SHOWS THAT YOU ARE RESPONSIBLE FOR YOUR MISTAKES, AND YOUR BOSS WILL FEEL CONFIDENT THAT YOU WILL FIX IT.

AS LONG AS YOU LEARN FROM YOUR MISTAKES, YOU WILL HAVE A FUTURE.

 

[ta3jbm]

Mistakes are inevitable, repeating past mistakes is intolerable. Experience basically means you have learned from those past mistakes. Mistakes should be admitted and shared for others in your group to grow from....in a perfect world.