Worst Professional Blunders...

Coming back to the topic under discussion - I have seen people get fired or demoted for making false disclosures, going against corporate policy, even for having porn on their company-supplied hardware (knowingly or unknowingly), or make too many personal phone calls on office time - but, I have not seen anyone face dire consequences for writing a bug...

So, I'd say that the probability that one might compromise his job by writing a bug is a lot lower than many of the other mistakes that one might do.

Quote:

---

Originally Posted by Siddhartha

- but, I have not seen anyone face dire consequences for writing a bug...

So, I'd say that the probability that one might compromise his job by writing a bug is a lot lower than many of the other mistakes that one might do.

---

Very true... But there are two type of bugs, and for one of them you can face dire consequences...

1) Unintentional Bugs... : Simply put, these are overlooked, Acidental, Typo (My top bug), Incorrect application of (someone elses) module(s) (mostly due to incorrect spec's) and Oversite...

2) Intentional Bugs... : Back door code (Bypass Security), Event logging (listing critical data such as usernames and passwords), Usage of redundant code to slow the application.

Any of these intentional bugs can land the programmer in a disaplinary hearing..

I've signed a contract that specified that any [b]intentional bugs[/i] (with a long list simular to above) will result in imidiate termination of contract and will lead to legal preceedings to recope losses incured, including Cost of 'Repairs' ..

Gremmy...

:D :D

"Intentional bug" (is that a bug, or a crime?) is akin to one ramming one's car into one's neighbour's home just because one doesn't like the neighbour... :D Chances are that the insurance wont cover damages, if it understood the motive...

Those that program viruses, or trojans that steal personal data while offering the user a seemingly cool utility / service could potentially end up in jail for really long periods... This is a felony.

My Worst Professional Blunder has to be the first business program that I wrote.
The entire project and the business relationships developed from it have been akin to setting myself on fire while eating acid.

I worked for this company as a machinist and they knew about my computer skills. I already did a few programs and some VBA stuff for them. Not only was I a machinist I handled a little paperwork and did tech work for the computer stuff.

They asked to write I program. I didn't know much and let them know.
After I started they cut my time on the project saying that if I didn't complete it with 80 hrs that I have to finish it on my time.
Of course this only amplified the piece of **** program to be an even bigger piece of ****. Though it ended up full of holes and bugs, it worked.

Even after I left the company 3 years ago. I still do a little consulting for them. Every now again I tweak the program a little. But every time there is huge argument about being paid. The new General Manager doesn't believe I should be paid becuase it's my program. LOL. I've gone over it with him several times about why I'm being paid to do this.

I still have the source for this project. They have a copy of source (or they should) from the first working copy.

I've venting a little bit here, they have been calling me for about a week now.

I have only lost one other customer, who I consulted for becuase of this bad deal. I think this time I'm just going to make it very clear to them I will not work for them.

Quote:

---

Originally Posted by Sabin_33

The new General Manager doesn't believe I should be paid becuase it's my program. LOL. I've gone over it with him several times about why I'm being paid to do this.

---

You startyed the program while an employee. Employee's are work for hire, and get paid for their labor (I am referring to in the USA), but do not own their work product.

Therefore you have every right to get compensated once you are a consultant.

Now comes the tricky part. If you modified the program (or created a new one), and were not clear (in a written contract) wether it was a "work-for-hire" or a "work product", then you could be legally libel (if is is deemed a "work product" to make it function properly without additional compensation (unless there was a written contract detailing limits of liability).

Rule #1 for ANYONE developing software outside of a strict employeer/employee relationship is to make sure that there are detailed contracts (my base contract runs about 17 pages) in place.

Quote:

---

Now comes the tricky part. If you modified the program (or created a new one), and were not clear (in a written contract) wether it was a "work-for-hire" or a "work product", then you could be legally libel (if is is deemed a "work product" to make it function properly without additional compensation (unless there was a written contract detailing limits of liability).

---

This indeed is the tricky part. Since I worked for the company as an employee, we never made a written contract. We had a few verbal contracts but they we all met by the time they started to use the program.

I do have copies of invoices issued in the past though. On those invoices is a disclaimer that I am not liable for the work.

I don't think something like this could escalate that much to a court order. I think I'll look for somebody else to take my place consulting for them.

I was once asked to fix this totally non-critical feature in a very critical application. The argument was "we really don't need it, but since it's documented you may as well make it work".

Bug #1 (my fault):
I added:

Code:

---

i = -1;

---

where I should have added:

Code:

---

i -= 1;

---

Bug #2 (my boss' fault):
Due to "too much to do" at the QA department I was told to test the application myself. My answer was "I'm not sure that's a clever decision. There is a good reason why we got a QA department, and there is probably a good reason why they've got too much to do...". Anyway, I was told to "think" like they did down at QA, and to do my best... I didn't find any bugs.

Bug #3 (the techies fault):
When done testing the application I went to the guy responsible for the software releases. He had the final word on any software that was released into the production environment. They had ofcourse strict rules on all software releases, planning, scheduling, avoiding peak hours etc, etc.. But apparently that didn't apply this day. The software went straight into production (at peak hour).

Bug #4 (operational departments fault):
It took about 2.4 seconds before the bug manifested itself and the CPU went straight to 100%. The first thing to be knocked out was ofcourse the software based KVM. Now we were blinded and in an early state of panic. The server then stopped resposning to network requests, with one exception. It was still sending 'OK' heartbeats to it's $100.000 passive failover server, so the failover server did nothing. In a higher state of panic they reasoned that "we need to pull the plug to terminate those heartbeats". So they did. All went silent.

After a couple of minutes they found the real reason why the active/passive failover solution didn't work. After a hardware test a couple of months earlier they never performed the manual failback routine, so we had been running on the failover server all the time while the main server was totally shut down.

Alot of phones went dead that day... but luckily I wasn't blamed :rolleyes:

- petter

petter,

That is exactly the type of tale I was looking for. A wonderful example of "the rule of 10's". I wonder if anything was done to the underlying business processes to reduce the rsik of this type of error happening again...

My worst blunder was ...

I was to write to a file a record id where I stopped printing the report for each day. And as each day begins, the program would start printing from the record id and stored where it stopped, in that same file. Unfortunately, I was told to store that file in some obscure places the operator wouldn't know, and I stored it in a system folder! As I was testing it, everything went fine because I was logged in as an administrator. However The operator logged in as a standard user, and you know the rest of the story. Well, that was long time ago.

Nowadays, to be compliant with Vista's UAC, programmers store their program-specific data or user data in those UAC recommended folders.

CBasicNet,

Thank you for your contribution. :wave: :wave:

For those who may be looking at this thread, there is a motive behind my posting....

I am currently putting some material together for publication. Part of this is a discussion on the "rule of 10's", which I firmly belive in (within an orer of magnidute, of course ;) )

All of the "blunders" listed so far, could have been easily avoided by following "standard" processes, yet these processes were either not in place, or not followed.

The eternal question is "How to get upper management to understand that placing and enforcing these policies SAVES MONEY!!! (and if you avoid a serious phyical injury, that involves a LOT of money!)

Sorry David...I don't make blunders as they tend to turn into fireballs...so I try my best not to do that, it has a tendency to ruin someones day.