Slashdot Mirror


The Rise and Rise of IT Administrators

maffstephens writes "Have you noticed how difficult it's become to develop software? Not because software is more complex, but because there seems to be an army of administrators standing in your way - sys admins, network admins, database admins, runtime admins - the list is endless. They should be there to help us, to make our lives easier, but the reality is often very different. This thought-provoking article from Software Reality is all about the emerging culture of spiteful, dog-in-the-manger prevention amongst corporate IT administrators. Software development has become so inefficient as a result, it's no wonder so many companies are outsourcing."

5 of 686 comments (clear)

  1. Declare independance by raider_red · · Score: 5, Interesting

    I work for a government agency in the U.S., and as you can imagine, it's saturated with sysadmins who watch over security, resource allocations, etc. Our solution was to build our own network infrastructure. We purchased two servers, cross-trained about six of us to work as admins on those servers, and completely bypassed the regular admins. The result is that we're one of the most productive organizations in our industry, because we were willing to put in a little extra effort to get around the problem.

    --
    It's good to use your head, but not as a battering ram.
  2. Re:In all areas by BinaryJono · · Score: 5, Interesting

    ditto on that.

    i just got word that my ex-school district is purchasing PDAs for every student enrolled in middle school and high school. when i was in 6th grade, i could barely keep track of my lunch money, nonetheless a PDA. id hate to see the rate of these things get broken/stolen/lost.

    in addition, the IT admins for our 2000+ high school didnt know what puTTY was and kept removing it from my personal storage folder out of fear of what it was. not to mention they stored their win2k domain password as one of the usernames (in the format "adminPASSWORD") in case they happened to forget it somehow.

    on the bright side, if im ever desparate for a job, i know one place i can go for sure. :)

  3. Not admins, not developers by Monoman · · Score: 5, Interesting

    What I often see is the people who least understand the big picture when it comes to technology are the ones who feel held back.

    The people I see getting mad just don't understand the impact or implications their "simple requests" may have on others.

    "Can't you just open up ports 135-139 in the firewall for everybody"?

    "It works fine on my system, something must be wrong with the server"

    and my all time favorite when people don't have a clue why their system isn't working ...

    "It must be the network"

    They really don't understand how their system works.

    As an admin (LAN, WAN, firewall, server, email, etc... you get the idea) for a med size (3000 users) organization I often have to learn other peoples jobs just to figure out what the heck they are really trying to accomplish. It usually goes something like....

    Customer: "We need ..."

    Me: "Why?"

    Customer: Pick one:
    1) Vendor says so
    2) We tried everything else
    3) Thats what someone else said
    4) ?

    Me: "What are you really trying to do?"

    Customer: "What do you mean?"

    Me: "Don't tell me what you think you need, tell me what you are trying to do?"

    Once I understand what someone is trying to accomplish then I can often work somethign out for them.

    --
    Keep the Classic Slashdot.
  4. Re:We Need Less Planning and More Coding by antarctican · · Score: 5, Interesting

    I agree that marching off to program with no planning would be silly. But I am a big believer in pathfinding programming, where you spend no more than a day building just enough of an application to illustrate the underlying design and/or interface.

    Then, come back and demontrate your idea to the larger group, with the expectation that more than likley you will throw the whole thing away.

    After a basic model has been developed that makes sense, only then sit down in meeting to flesh out the spec.


    And that's what I meant by prototypes, yes they're very useful, I just wrote one yesterday. I wrote a small proof of concept about some enhancements to Psort and on Monday I'll sit down and do it right - determining how to write the code without jamming it in with a shoe horn.

    And prototypes should be thrown away, most likely they're done with very poor quality. I recall one of my old profs when teaching us this made us write out prototype in a different language from what he wanted the final product in to "force us to not reuse it." Perhaps that's a bit extreme, but it illustrated the point. :)

  5. Author is right on the money by Iamnoone · · Score: 5, Interesting

    Many of the posters who disagree with the author, wrap themselves in the flag of "looking after the company's interests" - well who the hell do you think the developers are working for? - they aren't just making shit up on their own - Its the managerial idiots in the company who want you to roll out "Project I Pulled Out of My Ass So I Can Feel Important # 15" and no I would give you business requirement because this project is too overdue already just back fill them from the tech spec you guys make up and oh, yeah its important you follow all the processes and work nice with the poor "we're only trying to do our job" Operations Dept. And by the way if its late or wrong (because you read my mind incorrectly) then its your ass, not anyone else's.

    He is right, admins have too much power and too little responsibility for being on the line for projects getting rolled out.

    Here are some tidbits from one of my jobs at a Fortune 100 Co:

    When I first started working at CoX there were no UNIX tools on any of the UNIX servers prod or dev. I had to compile gzip, top, wget, perl and all the other tools needed for a normal system. Why didn't they need top or ntop, because if there were problems on the system they would throw up their hands and say it was because of the developers processes and called them/us.

    The network admins would refuse to participate in troubleshooting and no one else was allowed to use the sniffers. They would also do network work including taking switches and routers down during the nightly batch processing without notifying the "developers" who then got called at 4 AM to troubleshoot why "their" overnight processing failed.

    The Oracle DBA said that it was not possible for the same query to take different lengths of time to run(at different times).

    PC admins - no FTP GUI clients were on the list of approved software since the business users didn't need that type of product. No "shareware" allowed. They were starting to talk about no "shareware" for the UNIX servers around the time I was leaving :) I think they (IT management) think that things like wget is an example of what they would term "shareware".

    The security admins ruled that the r* commands are a "security risk" [period, blanket, no appeals] and the developers were give three weeks to change all the production processes - never mind that getting approval for a change request (from the tribunal of these idiots that run the change control "process") takes longer than that and all the code needs to be changed and tested before submitting the change request (into the IIS/VB million dollar change management system that could keep even the CIA from pulling any usable information from it). You will need to be prepared to justify any and all aspects of your project before the tribunal, even though they are the ones who are forcing you to make the changes.

    The list goes on and on. My experience across many jobs (20 years) being both an admin and a developers, is that generally admins are less competent and more useless than developers. The order in terms of least knowledgeable and most "preventative":
    1. Project Managers (completely and utterly useless)
    2. Security Admin (most seem obsessed with think that make the least difference for true security - ie patching iPlanet so that it doesn't do HTTP TRACE) Their job usually also involves the slimy, salacious task of monitoring people's email and looking through http server logs for who's downloading porn)
    2. (tied with security) Network Admins, won't help troubleshoot; nothing is wrong with the network; I can ping that machine from this one so its not the network; no you can't have any performance data about the net/router/switches its "confidential"; no you can't have the snmp password for the machines that you end up having to support because all the admins are useless, its "confidential"; no you can't use the sniffer, but its not the network so you don't need the sniffer anyway;
    3. DBAs (The