RE: Good HR vs. Bad HR...
give me a break! It took me 25+ years to get to the point where I have a group who will listen to me. And that's only one small group in the larger group I support, I doubt I'll be that lucky across the board |+---> || | || | || ksmith2@myfir| || stlink.net | || | || 05/10/2002 | || 11:08 PM | || Please | || respond to | || ORACLE-L | || | |+---> >| || | To: [EMAIL PROTECTED] | | cc: (bcc: Rachel Carmichael) | | Subject: RE: Good HR vs. Bad HR... | >| Hum, I have to fight a bit more for mine suggestions to go through. That's not fair. I guess its good for me as its helping my debating skills:-) It does not help that the folks I work with are half way across the country. -Original Message- [EMAIL PROTECTED] Sent: Friday, May 10, 2002 6:38 AM To: Multiple recipients of list ORACLE-L Don, Next time I need to resign, will you help me write the letter? Having worked at several large and not-so large companies, all I can say is, the problems you documented seem to be ubiquitous throughout most management. I have found it nearly impossible in some places to do my job with any degree of accuracy, because management has its own version of reality and if what I said didn't conform, it was thrown out. Something akin to deciding what the results of that physics experiment should be before beginning it, and throwing out all results that don't support the hypothesis. What amazes me is that these companies continue to survive in the face of such insanity. So far, it does not look to be like that here. I have reviewed and made suggestions in the past two weeks and the response has been "she's right, let's do it". And it gets done. I might actually like it here :) Rachel |+---> || | || | || granaman@cox.| || net | || | || 05/09/2002 | || 06:37 PM | || Please | || respond to | || ORACLE-L | || | |+---> >| || | To: [EMAIL PROTECTED] | | cc: (bcc: Rachel Carmichael) | | Subject: Re: Good HR vs. Bad HR... | >| I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both c
RE: Good HR vs. Bad HR...
I wish I can work for you beside learning Oracle I can be a wiser man. -Original Message- From: Don Granaman [mailto:[EMAIL PROTECTED]] Sent: 11 May 2002 00:38 To: Multiple recipients of list ORACLE-L Subject: Re: Good HR vs. Bad HR... Actually, I don't think the company is all that bad now. In fact, I would have preferred to keep the company name out of it. Also, I should have put this into a context. At the time this was written, upper management had started an intimidation campaign. They were doing some layoffs, but rather than do it in any kind of normal fashion, they were laying off one or two people per day - and making a spectacle of it. They would come around to the victim and force them to stop whatever they were doing immediately and parade them out of the building with a security escort. They were not allowed to even log off, finish a line of code, or pick up personal items - which were instead to be shipped to their home. After about a week or two of this, I happened to be on an elevator with a VP and a director (ones I didn't really know) - just the three of us. They started talking, for my benefit obviously, about the success of their "let's put the fear of God into our employees" (a direct quote) strategy. It was then that I decided it wasn't someplace I wanted to stay. That night, I wrote up this resignation - as a sort of counter-attack. The next morning, I came in, packed up most of my stuff, took it to the car, and submitted the letter to about three layers of management above me, the managers whose projects I was working on, one of the owners of the company, and HR. Most were included only because I wanted them to know why I was actually leaving, not some distorted version they might get through the bureaucracy. I also sent a fairly comprehensive turnover document to one of my co-workers (Mike M.), as I knew that this wouldn't be considered as an essential part of the exit process. About three hours later I was called up to HR. The director of the division I worked for was there, as well as the HR person. The HR person said that they had "chosen to terminate my employment effective immediately". I said "So, you are accepting my resignation?" and she turned bright red and glowered at me. She said that I wouldn't be able to return to my cube - that security would escort me out of the building directly from her office. I told them that all I had left there was one small box of books that belonged to me. This director was actually a very sensible and technical guy who had come up through the ranks. He told the HR clown that he would go back with me and escort me out. We went back to my cube, he carried the box out to my car for me, and told me "Well, at least maybe this will do some good". I think they slacked up a bit after that. I still have friends who work there. About a year after I left, I saw one of my past managers at a user group meeting. He is now a VP I believe. He said that if I ever decided I could work there again, to give him call. About two years after I left, I went back out there for a visit and was greeted warmly by former co-workers and even a few managers. I think that the reason that, as Matt said, this became "legendary" is only because it was a sort of "suicide attack" against the arrogance and stupidity that existed in some upper management circles at that time. I was the first "martyr", but quite a number of others also resigned within the next few months (none so flamboyantly though). Of the group (ET) of twenty that I was in, well over half had left (voluntarily) within a year. Matt was among the "defectors", as was our manager and a large percentage of the other senior technical people. Don Granaman [OraSaurus] - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, May 10, 2002 9:33 AM > Don, > > And, of course, since it was a resignation letter, the company probably just > filed it away. I'll give you the "Brass Cajones" award though, for setting > the record straight. > > Just curious, is the company still around? Need to make sure to avoid it in > the future! :) > > Tom Mercadante > Oracle Certified Professional -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Don Granaman INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
RE: Good HR vs. Bad HR...
Hum, I have to fight a bit more for mine suggestions to go through. That's not fair. I guess its good for me as its helping my debating skills:-) It does not help that the folks I work with are half way across the country. -Original Message- [EMAIL PROTECTED] Sent: Friday, May 10, 2002 6:38 AM To: Multiple recipients of list ORACLE-L Don, Next time I need to resign, will you help me write the letter? Having worked at several large and not-so large companies, all I can say is, the problems you documented seem to be ubiquitous throughout most management. I have found it nearly impossible in some places to do my job with any degree of accuracy, because management has its own version of reality and if what I said didn't conform, it was thrown out. Something akin to deciding what the results of that physics experiment should be before beginning it, and throwing out all results that don't support the hypothesis. What amazes me is that these companies continue to survive in the face of such insanity. So far, it does not look to be like that here. I have reviewed and made suggestions in the past two weeks and the response has been "she's right, let's do it". And it gets done. I might actually like it here :) Rachel |+---> || | || | || granaman@cox.| || net | || | || 05/09/2002 | || 06:37 PM | || Please | || respond to | || ORACLE-L | || | |+---> >| || | To: [EMAIL PROTECTED] | | cc: (bcc: Rachel Carmichael) | | Subject: Re: Good HR vs. Bad HR... | >| I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the first time that most of us even heard about this project.) We tested a variation of this method for CIT client
Re: Good HR vs. Bad HR...
Actually, I don't think the company is all that bad now. In fact, I would have preferred to keep the company name out of it. Also, I should have put this into a context. At the time this was written, upper management had started an intimidation campaign. They were doing some layoffs, but rather than do it in any kind of normal fashion, they were laying off one or two people per day - and making a spectacle of it. They would come around to the victim and force them to stop whatever they were doing immediately and parade them out of the building with a security escort. They were not allowed to even log off, finish a line of code, or pick up personal items - which were instead to be shipped to their home. After about a week or two of this, I happened to be on an elevator with a VP and a director (ones I didn't really know) - just the three of us. They started talking, for my benefit obviously, about the success of their "let's put the fear of God into our employees" (a direct quote) strategy. It was then that I decided it wasn't someplace I wanted to stay. That night, I wrote up this resignation - as a sort of counter-attack. The next morning, I came in, packed up most of my stuff, took it to the car, and submitted the letter to about three layers of management above me, the managers whose projects I was working on, one of the owners of the company, and HR. Most were included only because I wanted them to know why I was actually leaving, not some distorted version they might get through the bureaucracy. I also sent a fairly comprehensive turnover document to one of my co-workers (Mike M.), as I knew that this wouldn't be considered as an essential part of the exit process. About three hours later I was called up to HR. The director of the division I worked for was there, as well as the HR person. The HR person said that they had "chosen to terminate my employment effective immediately". I said "So, you are accepting my resignation?" and she turned bright red and glowered at me. She said that I wouldn't be able to return to my cube - that security would escort me out of the building directly from her office. I told them that all I had left there was one small box of books that belonged to me. This director was actually a very sensible and technical guy who had come up through the ranks. He told the HR clown that he would go back with me and escort me out. We went back to my cube, he carried the box out to my car for me, and told me "Well, at least maybe this will do some good". I think they slacked up a bit after that. I still have friends who work there. About a year after I left, I saw one of my past managers at a user group meeting. He is now a VP I believe. He said that if I ever decided I could work there again, to give him call. About two years after I left, I went back out there for a visit and was greeted warmly by former co-workers and even a few managers. I think that the reason that, as Matt said, this became "legendary" is only because it was a sort of "suicide attack" against the arrogance and stupidity that existed in some upper management circles at that time. I was the first "martyr", but quite a number of others also resigned within the next few months (none so flamboyantly though). Of the group (ET) of twenty that I was in, well over half had left (voluntarily) within a year. Matt was among the "defectors", as was our manager and a large percentage of the other senior technical people. Don Granaman [OraSaurus] - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, May 10, 2002 9:33 AM > Don, > > And, of course, since it was a resignation letter, the company probably just > filed it away. I'll give you the "Brass Cajones" award though, for setting > the record straight. > > Just curious, is the company still around? Need to make sure to avoid it in > the future! :) > > Tom Mercadante > Oracle Certified Professional -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Don Granaman INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Good HR vs. Bad HR...
>> So far, it does not look to be like that here. I have reviewed and made >> suggestions in the past two weeks and the response has been "she's right, >> let's do it". And it gets done. I might actually like it here :) Careful... they will slap you down when you least expect it! :-) RF -Original Message- [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 9:38 AM To: Multiple recipients of list ORACLE-L Don, Next time I need to resign, will you help me write the letter? Having worked at several large and not-so large companies, all I can say is, the problems you documented seem to be ubiquitous throughout most management. I have found it nearly impossible in some places to do my job with any degree of accuracy, because management has its own version of reality and if what I said didn't conform, it was thrown out. Something akin to deciding what the results of that physics experiment should be before beginning it, and throwing out all results that don't support the hypothesis. What amazes me is that these companies continue to survive in the face of such insanity. So far, it does not look to be like that here. I have reviewed and made suggestions in the past two weeks and the response has been "she's right, let's do it". And it gets done. I might actually like it here :) Rachel |+---> || | || | || granaman@cox.| || net | || | || 05/09/2002 | || 06:37 PM | || Please | || respond to | || ORACLE-L | || | |+---> >| || | To: [EMAIL PROTECTED] | | cc: (bcc: Rachel Carmichael) | | Subject: Re: Good HR vs. Bad HR... | >| I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the
RE: Good HR vs. Bad HR...
Wow, it's a small world. My first DBA position was at CSG Systems! And yes, the company broke off of First Data and became its own publicly traded company. By the way, nice letter :) -Original Message- Sent: Friday, May 10, 2002 10:33 AM To: Multiple recipients of list ORACLE-L Don, And, of course, since it was a resignation letter, the company probably just filed it away. I'll give you the "Brass Cajones" award though, for setting the record straight. Just curious, is the company still around? Need to make sure to avoid it in the future! :) Tom Mercadante Oracle Certified Professional -Original Message- Sent: Thursday, May 09, 2002 6:38 PM To: Multiple recipients of list ORACLE-L I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the first time that most of us even heard about this project.) We tested a variation of this method for CIT client installations and determined that it was impractical. How does one do such a poor job and yet convince everyone they are a "genius"? Is perception is truly everything here? To further compound the problem, we were never allowed to question or even review anything - not the application, not the database, and not the schema. The whole mess was a well-guarded secret until the very Friday afternoon that this consultant's contract was over and he left the company. At that time, it was turned over to us. We very quickly discovered that almost nothing actually worked. We were told that it absolutely had to go live Monday morning and that the deadline was totally inflexible. Then, in a rather nasty and threatening tone, we were told that we would just have to work over the weekend to "fix it" and install the Oracle client on 400 PCs. Since the only way to actually fix this disaster was to redesign and rewrite significant portions of it, we insisted that this "plan" wasn't realistic. How could we be expected to repair nine months of damage in a single weekend - in our "spare time" while also doing 400 client installations? The response was that we were simply "not team players". --- Another significant aspect of my dissatisfaction is that management quite frequently fails to understand (or even question) the usefulness of tasks assigned. I have been assigned many tasks that were said to be "urgent and critical" only to have the results discarded when completed. I have several clas
RE: Good HR vs. Bad HR...
Don, And, of course, since it was a resignation letter, the company probably just filed it away. I'll give you the "Brass Cajones" award though, for setting the record straight. Just curious, is the company still around? Need to make sure to avoid it in the future! :) Tom Mercadante Oracle Certified Professional -Original Message- Sent: Thursday, May 09, 2002 6:38 PM To: Multiple recipients of list ORACLE-L I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the first time that most of us even heard about this project.) We tested a variation of this method for CIT client installations and determined that it was impractical. How does one do such a poor job and yet convince everyone they are a "genius"? Is perception is truly everything here? To further compound the problem, we were never allowed to question or even review anything - not the application, not the database, and not the schema. The whole mess was a well-guarded secret until the very Friday afternoon that this consultant's contract was over and he left the company. At that time, it was turned over to us. We very quickly discovered that almost nothing actually worked. We were told that it absolutely had to go live Monday morning and that the deadline was totally inflexible. Then, in a rather nasty and threatening tone, we were told that we would just have to work over the weekend to "fix it" and install the Oracle client on 400 PCs. Since the only way to actually fix this disaster was to redesign and rewrite significant portions of it, we insisted that this "plan" wasn't realistic. How could we be expected to repair nine months of damage in a single weekend - in our "spare time" while also doing 400 client installations? The response was that we were simply "not team players". --- Another significant aspect of my dissatisfaction is that management quite frequently fails to understand (or even question) the usefulness of tasks assigned. I have been assigned many tasks that were said to be "urgent and critical" only to have the results discarded when completed. I have several classic examples… Case in point: During the very early stages of Telephony development, Steve Flott and I were assigned the task of writing "data injectors" to populate the Telephony tables for RACP testing. We were told this was of paramount importance and had to be done in less than two weeks
Re: Good HR vs. Bad HR...
Don - Excellent letter! Wonder what happened after you left? Did anything change? >>> [EMAIL PROTECTED] 05/09/02 06:37PM >>> I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the first time that most of us even heard about this project.) We tested a variation of this method for CIT client installations and determined that it was impractical. How does one do such a poor job and yet convince everyone they are a "genius"? Is perception is truly everything here? To further compound the problem, we were never allowed to question or even review anything - not the application, not the database, and not the schema. The whole mess was a well-guarded secret until the very Friday afternoon that this consultant's contract was over and he left the company. At that time, it was turned over to us. We very quickly discovered that almost nothing actually worked. We were told that it absolutely had to go live Monday morning and that the deadline was totally inflexible. Then, in a rather nasty and threatening tone, we were told that we would just have to work over the weekend to "fix it" and install the Oracle client on 400 PCs. Since the only way to actually fix this disaster was to redesign and rewrite significant portions of it, we insisted that this "plan" wasn't realistic. How could we be expected to repair nine months of damage in a single weekend - in our "spare time" while also doing 400 client installations? The response was that we were simply "not team players". --- Another significant aspect of my dissatisfaction is that management quite frequently fails to understand (or even question) the usefulness of tasks assigned. I have been assigned many tasks that were said to be "urgent and critical" only to have the results discarded when completed. I have several classic examples* Case in point: During the very early stages of Telephony development, Steve Flott and I were assigned the task of writing "data injectors" to populate the Telephony tables for RACP testing. We were told this was of paramount importance and had to be done in less than two weeks by doing "whatever it takes". After we started and saw how immature the design was, we questioned whether this task was premature. The design was changing as fast as we could write code. We worked 60-70 hours weeks until it was done. Every time we were
Re: Good HR vs. Bad HR...
Don, Next time I need to resign, will you help me write the letter? Having worked at several large and not-so large companies, all I can say is, the problems you documented seem to be ubiquitous throughout most management. I have found it nearly impossible in some places to do my job with any degree of accuracy, because management has its own version of reality and if what I said didn't conform, it was thrown out. Something akin to deciding what the results of that physics experiment should be before beginning it, and throwing out all results that don't support the hypothesis. What amazes me is that these companies continue to survive in the face of such insanity. So far, it does not look to be like that here. I have reviewed and made suggestions in the past two weeks and the response has been "she's right, let's do it". And it gets done. I might actually like it here :) Rachel |+---> || | || | || granaman@cox.| || net | || | || 05/09/2002 | || 06:37 PM | || Please | || respond to | || ORACLE-L | || | |+---> >| || | To: [EMAIL PROTECTED] | | cc: (bcc: Rachel Carmichael) | | Subject: Re: Good HR vs. Bad HR... | >| I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the first time that most of us even heard about this project.) We tested a variation of this method for CIT client installations and determined that it was impractical. How does one do such a poor job and yet convince everyone they are a "genius"? Is perception is truly everything here? To further compound the problem, we were never allowed to question or even review anything - not the application, not the database, and not the schema. The whole mess was
Re: Good HR vs. Bad HR...
[EMAIL PROTECTED] wrote: > I think enough has been said already - I didn't intend to name the company at all. >Actually, I > don't think that I said that all the managers were incompetent. (A select few in >the wrong places > perhaps.) Since the cat is out of the bag though, I will try to end this here and >now. > > I had a number of specific and well-documented "complaints", so I fired off this >kamikaze > resignation letter - straight through three layers of management, even cc'ing one of >the two owners > of the company. The original formatting was better, but here it is in ASCII. oh damn, can i get you to help author my resignation the next time i get to do one? please? -- -- Bill "Shrek" Thater ORACLE DBA [EMAIL PROTECTED] You gotta program like you don't need the money, You gotta compile like you'll never get hurt, You gotta run like there's nobody watching, It's gotta come from the heart if you want it to work. Dreams are free, but you get soaked on the connect time. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: bill thater INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Good HR vs. Bad HR...
I think enough has been said already - I didn't intend to name the company at all. Actually, I don't think that I said that all the managers were incompetent. (A select few in the wrong places perhaps.) Since the cat is out of the bag though, I will try to end this here and now. I had a number of specific and well-documented "complaints", so I fired off this kamikaze resignation letter - straight through three layers of management, even cc'ing one of the two owners of the company. The original formatting was better, but here it is in ASCII. --- [...] --- It is demoralizing also to see a parade of "experts", "gurus", and "geniuses" hand off botched, half-baked, poorly designed, and dysfunctional systems, then get major promotions and/or commendations. Case in point: The CIS applications were handed over to Wanda Kelley and I as upper management mourned the loss of their "Oracle genius" (a direct quote). Well this "genius" left us a system with almost no data integrity - there were only two foreign keys for 44 tables. Only about 70% of the tables even had a primary key. There were no check constraints or triggers to enforce data integrity. Nothing was enforced in the application. And the application handled extremely few of the business requirements. For example, the application does not function properly unless LOGONID in the EMPLOYEE table is unique. There was no such uniqueness constraint. Furthermore, the application uses "where upper(LOGONID) = :some_variable", so a uniqueness constraint alone is insufficient - there also needs to be a method to enforce uppercase only on this column on inserts and updates. There was none. One could enter a new employee record, then immediately query for it, exactly as entered, and not find it! Both copies of the Oracle control file were in the same directory. The online redo logs were not mirrored. While these and other basic errors and omissions were obvious to us untrusted flunkies, the "genius" overlooked them. The users were connecting to the database as the SYSTEM user (with the default password "MANAGER" of course). His project plan included installing SQL*Net on hundreds of PC's using WCSGCOPY. This doesn't work, all it does is remove the ORACLE_HOME directory and replace it with files copied from a server. It doesn't update the registry and it doesn't consider that there may already be an Oracle client on the machine (typically, there is - and it includes things that this method would delete, like the Oracle forms runtime). This last item became an issue when I first heard of it less than a week before the implementation date. (Incidentally, that was the first time that most of us even heard about this project.) We tested a variation of this method for CIT client installations and determined that it was impractical. How does one do such a poor job and yet convince everyone they are a "genius"? Is perception is truly everything here? To further compound the problem, we were never allowed to question or even review anything - not the application, not the database, and not the schema. The whole mess was a well-guarded secret until the very Friday afternoon that this consultant's contract was over and he left the company. At that time, it was turned over to us. We very quickly discovered that almost nothing actually worked. We were told that it absolutely had to go live Monday morning and that the deadline was totally inflexible. Then, in a rather nasty and threatening tone, we were told that we would just have to work over the weekend to "fix it" and install the Oracle client on 400 PCs. Since the only way to actually fix this disaster was to redesign and rewrite significant portions of it, we insisted that this "plan" wasn't realistic. How could we be expected to repair nine months of damage in a single weekend - in our "spare time" while also doing 400 client installations? The response was that we were simply "not team players". --- Another significant aspect of my dissatisfaction is that management quite frequently fails to understand (or even question) the usefulness of tasks assigned. I have been assigned many tasks that were said to be "urgent and critical" only to have the results discarded when completed. I have several classic examples… Case in point: During the very early stages of Telephony development, Steve Flott and I were assigned the task of writing "data injectors" to populate the Telephony tables for RACP testing. We were told this was of paramount importance and had to be done in less than two weeks by doing "whatever it takes". After we started and saw how immature the design was, we questioned whether this task was premature. The design was changing as fast as we could write code. We worked 60-70 hours weeks until it was done. Every time we were ostensibly finished we were given more extensive design changes and told to rewrite the code to fit the new design. We did this
