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).
Received on Thu May 09 2002 - 17:37:54 CDT
