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_at_cox.|

|        |          net          |

|        |                       |

|        |          05/09/2002   |

|        |          06:37 PM     |

|        |          Please       |

|        |          respond to   |

|        |          ORACLE-L     |

|        |                       |

|--------+----------------------->
  >----------------------------------------------------|
  |                                                    |
  |       To:     ORACLE-L_at_fatcity.com                 |
  |       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" <ORACLE-L_at_fatcity.com>
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 - matt.adams_at_appl.ge.com
> 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" <ORACLE-L_at_fatcity.com>
> 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: granaman_at_cox.net
>
> 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: ListGuru_at_fatcity.com (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: granaman_at_cox.net

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: ListGuru_at_fatcity.com (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: Rachel_Carmichael_at_Sonymusic.com

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: ListGuru_at_fatcity.com (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).