>> 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 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 twice. After we finished the third version, we found out that the RACP testing of Telephony had been indefinitely postponed because of the application's instability/immaturity. (Was the fact that code, or at least the design, has to actually work before you can do meaningful performance testing a new and profound revelation to someone?) Was this task simply a checkbox on someone's project plan? The decision to delay or forego immediate performance testing had been made nearly a week earlier, but we had not been informed. We worked long hours for a week after even the pretense of a need had evaporated - all because of CSG's abysmally poor interdepartmental communications. In all, we worked about a month of heavy overtime to write code that was never used. Case in point: I was once given the task of doing a performance review of the CIT code and system. I spent more than a week extensively analyzing the code - running tkprof, and writing up recommendations. There were a number of simple-to-fix problems. One of them was the use of literals instead of bind variables. When finished, the response I received was akin to "why are you being a troublemaker?". Evidently management was expecting a rubber-stamp approval. The official response was "we don't have the time or resources to change it". So why bother doing the testing? About six months later, Ke Qiu was assigned the same task for the Phoenix code. His conclusions substantiated mine. The lessons that should have been learned from the CIT testing had no impact on Phoenix development. Many months later CSG hired a consultant to come in and do performance testing and make recommendations. Guess what? His testing revealed basically the same set of problems that Ke and I had documented much earlier. What was the point? Why was so much money and time wasted repeating essentially the same task over and over when the results were so consistently ignored? Case in point: I was given the task of designing and writing a method of purging off expired CIT records. CIT accumulates a lot of data, most of which needs to be eventually purged off. I was given a long document containing the purge specifications - so detailed as to even contain the SQL where clauses for all the appropriate tables. I worked on this for about a week. I wrote a package to do the purge, generated millions of records of test data, tested it, tuned it, documented it, put it into source control, and jumped though all the hoops. When I was about to put it into production, I was informed that it wasn't correct. The entire method of choosing which records to purge was based on the wrong criteria. When I responded by showing how the code did indeed faithfully implement the design specs, I was informed that the specs were wrong. Even though I had asked several key people on the project to review them before I started and nobody indicated any problem - including the author. This code, to the best of my knowledge, was never installed and has never been run. If I had been a bit less nanomanaged, perhaps someone could have given me the actual requirements instead of low-level details of how they wanted it implemented. But, I guess it must be against company policy to trust employees to actually think. Too bad. I used to teach physics and also have a degree in applied mathematics. I am actually quite good at "story problems". --- [...] --- PS: If the above spawns a witch hunt for any particular parties, you have missed the point. I regard the current manager and past managers of the database group as all very good and well-intentioned. I think that this is true of the vast majority of the people with whom I have worked while here. Unfortunately, they are also constrained by the corporate culture. --- Don Granaman [OraSaurus] ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Thursday, May 09, 2002 11:52 AM > Unfortunately, I don't have a copy of it. This was a number of years ago > (5? 6?) when we both worked at CSG Systems. > > Don, correct me if I mis-remember something here. > > IIRC, I came back from > being gone for a week (conference or vacation, don't remember which), > and Don was gone, but the whole place was talking about that > letter. I got a chance to read it, but didn't save a copy. > > It basically outlined why almost everyone in management > (especially the managers of the Phoenix project) was an incompetent fool. > > > ---- > Matt Adams - GE Appliances - [EMAIL PROTECTED] > Reason is 6/7ths of treason. - The Xtals > > > -----Original Message----- > Sent: Thursday, May 09, 2002 12:14 PM > To: Multiple recipients of list ORACLE-L > > > This is getting too good we need to see that letter now. > > Rodd > > On Thu, 2002-05-09 at 02:13, Adams, Matthew (GEA, MABG, 088130) wrote: > > Had to be CSG! Your resignation letter was legendary. > > -----Original Message----- > Sent: Wednesday, May 08, 2002 5:03 PM > To: Multiple recipients of list ORACLE-L > > > I was once "fired" because HR didn't like the tone of my resignation! > > Don Granaman > [OraSaurus] > > ----- Original Message ----- > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Wednesday, May 08, 2002 12:30 PM > > > > True story (my own...) > > > > "Dear ..., I am tendering my resignation ...." > > > > (to which HR returned it with) > > > > "Resignations must be made using form XYZ - please > > fill in the correct form and resend" > > -- > Please see the official ORACLE-L FAQ: <http://www.orafaq.com> > 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). > > -- 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Freeman, Robert 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).
