Re: The demise of the Oracle professional?

In article <a8c29269.0206150943.36adcd9f_at_posting.google.com>, you said (and I quote):

> - thought they were a designer, and came up
> with their own very bad designs.

Oh yeah, reminds me of the ERD I saw recently with 5 unresolved M-M relationships, all mandatory. And quite a few recursive 1-M relationships, with no optionality whatsoever. Basically an impossible situation to load data into.

But management was extremely impressed by the "presentation" and "approved" of the design...

> - thought that their people were SOOO good, when they
> were just beginners. This is often based on how much
> they like them.

Exactly. Collusion and nepotism. Let's call it by name, shall we?

> - thought that the only way to speed up performance,
> was to just add more and more hardware, not tune the
> SQL statements. By the time I got there and figured it
> all out, this had led to more bad decisions and
> cost millions!

That's all over the place, not just with Oracle. A common attitude since IBM started selling that idea back in the late 60's. Of course, IBM selling the same hardware that is supposed to be upgraded never sparked even a question of conflict of interest...

> So, with this lack of knowledge, it is impossible to
> determine what is correct and what it not. Are
> your people working well or not? Do you give them
> a bonus or fire them? How many people do you need
> for this project? How do you give them direction
> when you don't know what is involved? Do you let
> them guess and do trial and error, or insist that they
> do more analysis? How do you make decisions on a
> backup strategy, architecture, etc.? What is the
> most critical part of the project? How much time
> do you realistically allocate for a project without
> guessing? How do you ensure that things run smoothly,
> instead of having one emergency after another?

Tsk,tsk. Haven't you learned anything yet?

The IT managers' mantra:

• Come up with plans and schedules that are completely and utterly unrealistic.
• Force the staff to work absolutely silly, immoral work hours to meet these schedules. Threaten them with firing and the recession if they don't comply.
• When they deliver, call them a bunch of lazy bones who could have done a lot better. Half the next schedule timeline. And give your staff a bad review.
• When they don't deliver, call it "we did our best with the people we have", so that your staff get all the blame for their "incompetence". And give your staff a bad review.
• Put it to senior management that you're trying to "gauge accurate metrics" for the company's projects, when they complain to you about staff wanting to leave and the cost of training new people.
• Move sideways or "progress your career" as fast as possible, so that no one can pin you down for the complete, utter incompetent that you really are. Wipe all the M$ Project files from your system, just in case someone realizes that you have NEVER done a single resource levelling.

What's so hard to grasp here? IT management is dead easy! ;-)

> boss that does not know what it going on. You
> spend more time trying to educate them about the
> basics, than talking about the issues to get a decision.

Total and utter waste of time. They are not even remotely interested in learning anything, just in how fast they can "upgrade" their "career".

>
> True. With the new complexities of tech, it is impossible
> to know everything. I can't know everything about
> java either. So, it would be impossible for one manager
> to have all the certifications from CISCO, OCP, MSCE, etc.
>
> In which case, the way to manage all the different
> technology specialists, is like a CEO. The CEO does
> not know everything about accounting, engineering,
> sales, procuction lines, legal, HR. So, those are
> delegated to specialists in these areas. What then
> becomes important are the people skills to referee
> all these groups. But the CEO must still have a fair
> knowledge about these areas.
>

Absolutely.

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam