Trouble at the 9th layer.

[jack-rp9/bkPP+cDYtjvyW6yDsg at public.gmane.org (Jack)]

I to started back in the 'priesthood of computers' was prevalent.
That is thankfully long gone.

You are right about the 'internal hierarchy'.  I moved out of development
several years ago, and into system administration.  Interestingly more
folks go the other way... I've always done things differently it seems.

Some things seem to have changed a little since computers are now
considered a utility (no one thinks about it until it isn't there).
As a sysadmin you tend to be 'invisible or in trouble' these days.

In some companies the 'production' sysadmins hold the 'test/development'
folks in distain because they view life is 'they push it on me, and we
have to put wings on the pig to make it fly', typically because they have
been given incomplete development that was not regression tested with
data that is near enough to production like data.  And they feel they
are blamed for poor application performance even if it is inappropriate
application design and performance for whatever reason.  Most production
admins have been hit with it several times, if they have been in the
business for any time.

Developers and their support admins, sometimes don't understand
what it takes to do day to day administration.  But they also have a
disadvantage of not necessarily having proper production style data.
But as a developer, I found generating proper test data took almost
more effort than developing the application. (IMO and experience, it
is the boundary conditions that took much more effort to process
correctly than 99% of data that was well conforming to expectations.)

Enough of memory lane,

><> ... Jack


On Sun, Nov 29, 2009 at 6:54 AM, Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> wrote:

> I've been a developer the early 1970s. I've found that there is an
> unwritten pecking rule in many companies. Raytheon was certainly the
> most pronounced. In general at Raytheon Data Systems in the late 70s and
> early 80s, there was engineering, and within engineering there was a
> pecking order where the hardware people were above the software people.
> The next level was the IT programmers, then there was the 'computer
> operators'.  Basically, my experience at other companies the various
> groups had more respect for each other, but still the pecking order
> existed. Some developers wanted full control of all the hardware in
> engineering  including the servers.
> These hidden rules exist primarily in the minds of the players.
> Developers tend not to like to be in a box.
>
> At Raytheon in the late 90s, I was hired as a contractor by HP to write
> device drivers for HP-UX. In Bedford, the 3 HP guys had root privs on
> our workstations as well as some systems in the classified lab. But, in
> Sudbury, I needed to write a fibre optic device driver, and the IT
> people refused to give me root privs even though the systems were all in
> an engineering lab and the machine I was using was owned by HP. After 6
> weeks, they relented, but with the stipulation that I needed a Raytheon
> employee to sit next to me and watch all my keystrokes while I was
> logged in as root. They finally moved the fibre card down to Bedford.
>
>
>
> On 11/29/2009 12:01 AM, Rich Braun wrote:
> > Dan Ritter <dsr-mzpnVDyJpH4k7aNtvndDlA at public.gmane.org> suggested this warning about dev root:
> >
> >>   Attempting to violate this policy once will result in a
> >>   warning. A second attempt will probably be considered grounds
> >>   for termination of employment.
> >>
> >>   If you think you need expanded privileges on any machine,
> >>   please contact the sysadmin staff ...
> >>
> > Heh.  I am the guy in charge of the dev servers where I work.  If I sent
> that
> > out, the devs would instantaneously go over my head and I'd get a CTO or
> VP
> > directive that so-and-so gets root, period, on all dev boxes (and I've
> even
> > gotten that directive for two of the devs on all /production/ boxes).
> >
> > I try to bend over backwards and give the devs what they
> need--quickly--but
> > this is a battle I have not figure out how to win, at least in a small
> company
> > (IT organization of about 25-30 with 6 to 10 developers).
> >
> > But maybe it's a battle I should try again soon because most of the
> long-time
> > hires have disappeared--a lot of this office politics depends on
> longevity,
> > and now only one of the developers has been there longer than me.
> >
> > ISO 7-layer model: 8th layer = finance, 9th layer = politics.
> >
> >
>
> --
> Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
> Boston Linux and Unix
> PGP key id: 537C5846
> PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846
>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>