Forgot your password?
typodupeerror
Programming Technology IT

The Rise and Rise of IT Administrators 686

Posted by CowboyNeal
from the thorn-in-the-side dept.
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."
This discussion has been archived. No new comments can be posted.

The Rise and Rise of IT Administrators

Comments Filter:
  • by sleeeper (210375) * <slashdot AT bigelow-springs.net> on Saturday December 06, 2003 @01:30PM (#7648231) Homepage
    The most important point the article makes is that the people running the systems are no longer current/former developers.

    Because these "adminstrators" know little to nothing about development, I spend hours in meetings working on stifling buzz-word compliant "Enterprise Architecture" plans. If we all just sat down and coded first, our productivity would soar.

    In the time it takes to argue about how we might want to do something, I could literally have implemented betas of each ideas considered.

    • by wackybrit (321117) on Saturday December 06, 2003 @01:38PM (#7648304) Homepage Journal
      I disagree. We need to focus on the quality, not the quantity. We need better planning, not just less of it.

      I've been involved with companies who spend forever planning and twice as long coding, and they still produce crap. Why? Because the design is always done by committee, so no really good ideas get out there, and the design always ends up as a preoptimized mess with a few "management-approved" ideas thrown in.

      I seriously think a small tag-team (2 or 3 people) should be responsible for projects, and they should take in all of the input and recommendations, and produce a solid spec by themselves.. rather than the typical '10 departments sit around a table for 20 meetings and produce a piece of shit' method.
      • by Anonymous Coward on Saturday December 06, 2003 @03:10PM (#7648970)
        How do we get to "good planning"?

        In the "new age", where everyone and their brother got into computers because "that's where the money is", there are a number of real problems.

        1) The average skill level has greatly diminished. Thus, "the masses" have to be partitioned narrowly as they cannot, generally, operate on a big picture. So there are far fewer people who can actually plan, as that demands broader skills.

        2) Once you discover the need to partition on narrow skillsets, every partition comes with an automatic presumption of expertise vis a vis all others.

        3) Once you have "experts", you presumably want them to assert that authority. Thus you end up with network "experts", database "experts", web hosting "experts", ad nasium. Each, by definition, opertating in a clueless vacuum due to organizational structure, and the original reality that that structure was created to address the narrowness of skill found in most modern day technology people.

        4) Now that you've accepted a lower skillset per capita, and tanked up your organization with same, you created yourself a self-fulfilling prophecy. Each "expert" will basically refuse to co-operate with any higher functioning integrating authority out of self-preservation. Human nature will refuse to hire, cooperate, or contribute (to the maximum extent possible) to anyone that might threaten their status.

        In "the old days" the model you suggested was pretty much the norm. Execpt there was no need for 10 departments. Generally there were 3, Businss Analysis, Development, and Operations.

        Systems were, generally, "standardized" becuase the universe of potential staff was small and maximalizing technical diversity was not in anyone's best interests. There was no need to compete with your fellow technologies, there were few of them, and they all were in the buisness as a result of a legitimate calling.

        Today, hacks are the norm. There are a number of dubious stratigies employed to remain competative, none of which includes standardization or hiring "the best (and possibly better) people for the job.

        I'm an old-timer, watched it happen. I sit here, unemployed, today becuase I felt it important to hire "the best people", even if they were "better". Net-net, after 10 years, they still have jobs maintaining a system I designed and built for pennies on the dollar, played a role in moving from 80 to 250 million dollars a year, and enabled a host of standardized technologies like TCP and web. See, "we don't need generalists anymore" (they are "disruptive") was the reason everyone who actually contributed true-IP for this company was let go.

        From now one... I'm dumb, er "focused" in Corporate speak, narrowly skilled, and will never hire anyone that's bright enough to span technical disiplines. I'm just sorry I didn't get that message soon enough.

      • by PhotoGuy (189467) on Saturday December 06, 2003 @04:54PM (#7649657) Homepage
        I seriously think a small tag-team (2 or 3 people) should be responsible for projects, and they should take in all of the input and recommendations, and produce a solid spec by themselves.. rather than the typical '10 departments sit around a table for 20 meetings and produce a piece of shit' method.
        I very much agree with this statement. Most successful software projects I've seen always had one visionary behind them (or a very small core of 2 to 3 that work well together), and a great supporting cast. The core had the vision, the design talent, and the autonomy to make the final decision, hopefully with good input and proper execution from the team. (Where things fall apart is where you don't have the leader(s) with the vision, or who generally know what they're doing, or if you try to run the whole shop by committee. Accepting and valuing feedback from talented employees, does not require you run things like a democracy.

        I think the same is true of other areas of society, too. Armies are not led by committees, but by a strict hierarchy of responsibility, with one person responsible for the group below them, as you go up the chain. Not complete democracy, but it's the structure you need when you have to get things done. A good commander will listen to the feedback of his troops, but ultimately make the decision and be responsible for it. I find it a bit ironic that Western culture embraces democracy and distribution of control (in theory), but tends to use an autocratic structure when things are critical.

    • by Anonymous Coward on Saturday December 06, 2003 @01:39PM (#7648312)
      We Need Less Planning and More Coding

      Sounds like how they wrote Windows ME.

    • by antarctican (301636) on Saturday December 06, 2003 @01:40PM (#7648320) Homepage
      If we all just sat down and coded first, our productivity would soar.

      Umm, first you say the problem with these administrators is their not developers, then you say we should just sit down and code?

      Any good developer who paid attention in their software engineering course would know the further down the development cycle you get when you discover a problem with your specifications the more expensive it becomes to repair the problem.

      Make prototypes I can see, show the basic functionality and flow of the software. But before developing any large software project one must design the specifications and requirements.

      Any developer who doesn't understand this would fall into the same boat as these "non-developer administrators" in my opinion. Go pick up a software engineering book and re-read it. And make sure it's not eXtreme Programming, that book is how Windows-like disasters are made.
      • 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.

        • by antarctican (301636) on Saturday December 06, 2003 @02:04PM (#7648517) Homepage
          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 [psort.org] 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. :)
      • by Qzukk (229616) on Saturday December 06, 2003 @03:50PM (#7649246) Journal
        Any good developer who paid attention in their software engineering course would know the further down the development cycle you get when you discover a problem with your specifications the more expensive it becomes to repair the problem.

        And every developer with experience knows that if you took your client, beat their head against the wall for weeks, then finally cracked it open with a mallet, you're not going to get a specification to pop out. Even with the prototypes for demonstration purposes, if your boss/contract/whoever (how often are YOU in a position to do this) clamp down on the specifications at some point in the development cycle, your development cycle will never leave the "chasing new specifications" stage.

        Of course, its even worse when you're doing an in-house project and your boss is the one who decides that it needs to reach a "stable" point... but, "Oh, by the way, we haven't used it for two months because the address on the bills it prints is a quarter inch off from the window on the envelope. We really need to work on this billing part of the system." Thanks a lot, boss!
    • The further along through the development cycle you are, the harder (and more expensive) the change is. Sitting down and coding is a foolish way to think that productivity gains will happen. It'll simply cause ill-thought out and badly interoperating enterprise systems.

      And despite your sniff at "enterprise architecture" let's keep one thing in mind; both the coding and the planning are there not as an end in itself, but as a means for the enterprise to make more money so that you can continue to code.
    • by Daniel Dvorkin (106857) * on Saturday December 06, 2003 @01:51PM (#7648400) Homepage Journal
      OTOH, there's the problem that most developers got into that line of work because they want to, you know, develop. And most administrators ... etc.

      The solution, IMO, is for the developers to do exactly as much administration is needed (not nearly as much as most PHB's seem to believe) as a perhaps unpleasant but necessary ancillary duty of their job. Like cleaning out the coffeemaker at least once a week. ;) And for the wannabe administrators who don't know jack shit about anything useful to go find a job that makes use of their natural level of talent ... like, say, slinging burgers at McDonald's.

      Unfortunately, in the real world, we're never going to get rid of the PHB's and their sycophants. (As satisfying as the idea of them having to trade in their suits for fast-food uniforms may be.) So developers will keep doing what the author of the article describes: working around the bullshit to actually get things done.

      About the best piece of advice I can give anyone who's caught in a nightmare scenario where there's just too much bullshit to make the above practical is: look for a job at a smaller company. I've been working for a small business, with less PHB bullshit than probably 99% of the corporate development world as a whole, for about five years now, and I love it. You don't get the security you do with $Fortune_500_company_here, granted, and that does bother me sometimes. But the joy of actually being able to go into work and do my job more than makes up for it.
      • Speaking as one of the wannabe's who's already managed as if he was already flipping burgers, I would like to drop-kick all the wannabe coders who have passed through in the past few years.

        What most coders don't understand is that I have to support several thousand workstations and servers. Every few weeks, some application appears on the network that I've never seen and never heard of. I have no idea what it does or what resources it needs. It has no documentation nor any interface the likes of which
      • So developers will keep doing what the author of the article describes: working around the bullshit to actually get things done.

        This is exactly on target. Other replies here are bashing your comment, but this is definitely true. Frankly if we didn't circumvent the red-tape bullshit at my company, we would cease being productive.

        The bottom line is that to be efficient and productive you need to operate under the radar of the IT overlords who have this obsessive vision of making all of the computers in

    • Programmer centric (Score:3, Informative)

      by silas_moeckel (234313)
      OK first off I do this for a living and am an ex full time programmer. I left programming to leave working at big bussiness's slow pace. Having said that.

      Yes programmers should program more and go to meetings less; they have nothing to add to a meeting outside of thats hard thats imposible etc etc etc let, the one lead programmer or better yet the Systems Arch go to the meeting for the tech side. Yea it's they guys some programmers hate because they are technical and see through the BS while pushing inte
  • In all areas (Score:4, Interesting)

    by ScottCanto (705723) on Saturday December 06, 2003 @01:30PM (#7648235)
    The high school I attend is completely saturated with technology, but only half of it works half the time. We suffer from horrible ineffiency due for the most part to our ITs/admins who got put in a job they have no idea how to do. They can't contend with all they have before them and thus adopt a horrible attitude. Nobody wants to talk to them or be around them, and nothing gets done.
    • Re:In all areas (Score:3, Insightful)

      by g0hare (565322)
      Wonder how much it pays to be an admin in your school? Probably not much.
    • by DrEldarion (114072) on Saturday December 06, 2003 @01:43PM (#7648343)
      The computer tech at my high school was so incredibly incompetent. We eventually found out why - he had a degree in ART.
    • Re:In all areas (Score:5, Interesting)

      by BinaryJono (546830) on Saturday December 06, 2003 @01:44PM (#7648346)
      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. :)
      • Re:In all areas (Score:3, Insightful)

        by Lifewish (724999)

        Our school's sysadmins were crap. No really. The secretarial server - with all the confidential student and teacher data - had the unicode bug and they refused to fix it, can't remember why. Eventually, a friend and I got bored of seeing all our personal details on show (unencrypted SIMS) and went round and fixed it in 2 minutes.

        Our head of department once gave me a lecture over playing Flash games online cos they "could be virus-infected". If there's a way that this is possible, someone please tell me.

        T

        • Re:In all areas (Score:3, Insightful)

          by crawling_chaos (23007)
          Our head of department once gave me a lecture over playing Flash games online cos they "could be virus-infected". If there's a way that this is possible, someone please tell me.

          You mean like this? [f-secure.com] The vulnerability has been patched, but that doesn't mean the architecture isn't vulnerable to viruses anymore. Not to say that the administrator in question is the most brilliant guy in the world, but at least he stayed tuned in to his virus warnings.

      • Re:In all areas (Score:3, Insightful)

        by AKnightCowboy (608632)
        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.

        See the problem with these people though is that they are idiots. You get that in any field. They were probably ex-teachers who took 2 or 3 courses on learning Microsoft Office and suddenly got

  • by NetNinja (469346) on Saturday December 06, 2003 @01:31PM (#7648238)
    I have nothing against programmers. We have two of them and they are a delight to work with, except when they start breaching security protocols because it makes thier life eaiser to transport data or they are given Carte Blanch over servers to do with they want. Trying to clean up after thier mess is a nightmare in most cases.
    • I have to agree with the above completely. Too many developers know absolutely nothing about how the systems they want access to actually work. Schools are pumping out developers who are just plain coders, who don't know, and don't care, how the domain is setup, or how our print server is administered, or how a cluster works. And many of them have no care about security protocols. In a health organization, security protocols have now become a Big Deal.

      Cleaning up after code monkeys who wreck a productio
    • by epseps (39675) on Saturday December 06, 2003 @02:14PM (#7648581)

      That there is a reason why alot of admins are paranoid about giving anyone , not just developers, control of their box. The case in the article was an extreme example, but I couldn't help but wonder "What did some developer do years ago that completlty hosed everything?"

      The back up situation at the place in the article sounded outrageous. The author had every right to be angry about that.

      As far as the firewalls go..if there is a security breach, the developers would not get sacked and new abused ports are discovered. Users find ways of clogging everythign up with Yahoo! IM going through port 80, outside KaZAa users from Brazil suddenly thing that you have LTR Return of The King hidden somewhere on your network or script kiddies from Korea sudenly decide to scan port 1021 all day long...In other words, there are lots of reasons to change the configuration of a firewall daily (unless disconnected from the outside completlty..but no users want that).

      Like NetNinja said, cleaning up after them is a nightmare, plus the admins are liable for the mess , not the developers. Communication between groups is the key.

    • by FreeLinux (555387) on Saturday December 06, 2003 @02:34PM (#7648709)
      He has decided that his problems are due to administrators, who are all clueless, and that he would be so much better off if his world was run by developers, that are all knowing.

      The reality is that the authors problems are due to inept individuals and the corporate bureaucracy that keeps these inept individuals in place. The problems are not simply admins vs. developers. This is no different than any other profession.

      There are countless bad administrators out there. Many/most do not deserve the title of Administrator. But, at the same time, there are just as many developers out there that should not be allowed near a keyboard and yet they are forcing new "applications" down end user's throats on a daily basis, "applications" that reduce productivity due to bad design and processing inefficiency, buggy and untested code, and a total lack of understanding of the business process.

      There are far too many inept individuals on both sides of the fence. It is not about admins vs. developers.

      One more thing, the author seems to understand that J2EE is a bad idea so, why does he continue to develop with it?

  • Outsourcing (Score:3, Insightful)

    by eadz (412417) on Saturday December 06, 2003 @01:31PM (#7648244) Homepage
    Companies are outsourcing development becasue it can be cheaper, faster and better. Not becasue sys admins are in the way of developers.
  • Developers (Score:5, Insightful)

    by Joe U (443617) * on Saturday December 06, 2003 @01:33PM (#7648254) Homepage Journal
    Developers, Developers, Developers, Developers...
    (That's all I hear these days, thank you Steve Ballmer)

    As a sysadmin, the Devs need to learn how to play nice and keep the system stable. As a developer, I want total access to everything.

    Solution? Developer network off the main network. If they blow it up, it's their fault and they fix it. Sounds good in theory. I think programs like Ghost will play a big role in this type of setup.
    • by ayden (126539) on Saturday December 06, 2003 @02:52PM (#7648840) Homepage Journal
      Solution? Developer network off the main network. If they blow it up, it's their fault and they fix it. Sounds good in theory. I think programs like Ghost will play a big role in this type of setup.

      Yeah, we do that, but we in IT still end up supporting the people who can't be bothered to figure out who actually runs the development network. The development network is behind a firewall and we don't allow pings through (MS-Blaster and Lovesan containment). They run everything on their side of the firewall, DNS, domain controllers, AntiVirus (more frequently disabled or not installed), security patches (NEVER!) etc.

      Just before Thanksgiving, I got a call from one developer saying he couldn't reach the FTP server. My call back went something like this:

      IT: Can you describe the problem?

      DEV: I can't reach the corporate external FTP server. I can't ping it, either.

      IT: Pings are disabled between subnets and VLANS for antivirus reasons. How exactly are you trying to get to the FTP server?

      DEV: I go into Internet Explorer and type FTP in the location bar.

      IT: Can you get to the FTP server from the command line?

      DEV: You mean with ping?

      IT: No, by using FTP. Ping is blocked by the firewall and on the routers.

      DEV: Uhh.....

      IT: Open a command prompt. Type nslookup ...

      DEV: You mean ping?

      IT: No, type nslookup ftp.

      DEV: It came back with Non-existent domain.

      IT: Right. What does it say is your DNS server?

      DEV: Develop. It's our Primary Domain Controller.

      IT: Let's try using the IP address type ftp xxx.xxx.xxx.xxx.

      DEV: Hey, I got a login prompt. Let me try this in Internet Explorer. OK it works.

      IT: Do you know who administers the PDC/DNS server you're connected to?

      DEV: I think IT does.

      IT: No, we don't. It's part of the development network. You have a name resolution problem. Try contacting the system's administrator and have them correct the name resolution problem.

      DEV: But shouldn't I be able to ping the FTP server?

      IT: (Stunned silence) ... No, pings are blocked between subnets, VLANS and from behind firewalls to block MS-Blaster and Lovesan. Even when if you could resolve the FTP server name, ping will not work...
  • power corrupts (Score:4, Insightful)

    by fulana_lover (652004) on Saturday December 06, 2003 @01:33PM (#7648258)
    absolutely. i work in a f500 corporation and as the dev manager i spend half my time convincing the program manager to convince the IT guys to let our stuff trickle out. i can totally see the IT managers point, that his job is to keep everything up all the time and if everything is changing underneath him, he can't do that! i am at least happy we have our own sandbox (which we manage, the IT folks will only swap out hardware, apply security patches, or format, nothing else), and we hand over new software releases on a quarterly basis. I don't think there really is any other way to do it, can't have random groups deploying software to production servers, i don't think the CEO or CIO would want to hear the finger pointing blame game when something goes wrong. gotta be a better way tho...
  • by wackybrit (321117) on Saturday December 06, 2003 @01:34PM (#7648264) Homepage Journal
    I've noticed that in-house development is harder too, but I blame a few different things. Politics and the work climate. Nowadays, admins know they can lose their job at the drop of a hat, and as such, they're getting a lot more defensive. Particularly with programmers whose systems might make their jobs a whole lot easier, making them more replaceable!

    When you outsource coding, this problem is highlighted more, meaning management can finally do something. In-house programmers are more likely to sit around playing Solitaire and twiddling thumbs when they get a frosty reception from the admins. Freelancers and external people need to show progress before they get their paycheck, so they aren't scared to call out the BS within an organization, or grass up sloppy admins to their bosses.

    This is why I'm a freelance programmer. I get to work for lots of different clients, but I also get to see the internal politics from a higher level. I can tell management about the BS going on at the lower levels, and look like I'm doing my job while I'm at it (because I am).
    • by quantum bit (225091) on Saturday December 06, 2003 @02:33PM (#7648703) Journal
      When you outsource coding, this problem is highlighted more, meaning management can finally do something.

      The only problem is that outsourced programming often times SUCKS. It's usually commissioned by management with little or no input from the people who will end up supporting it.

      I have the unfortunate job of managing a large number of Windows 2000 workstations, but have them locked down so that users can't install random crapware or muck with the system settings.

      Over the years we've had a few custom programs developed on a contract basis by outside companies. Most of them are buggy, slow (Visual Basic crap), and make assumptions they shouldn't. It annoys me to no end when users complain that the software isn't working and it turns out to be that the software is badly designed and is trying to write to files inside of the program directory or modify the HKEY_LOCAL_MACHINE registry hive. I mean you don't see many *NIX programs that demand write access to /usr/bin or /etc... I've even seen this in some commercial software: AutoCAD LT, ACT, etc.

      Fortunately, our in-house developers are pretty clueful and their stuff usually works without a hitch.
  • Excuse me? (Score:5, Informative)

    by antarctican (301636) on Saturday December 06, 2003 @01:35PM (#7648271) Homepage
    We're a cancer?

    I think it's more that the software development cycle is becoming move evolved, as happened to engineering a few decades ago. The days of slapping things together and getting it out the door are gone, and good thing, we all see what occurred at Microsoft when quality wasn't a top priority. Buggy software with huge security holes.

    IF we want the public to trust software and computers more we have to develop a more "engineering" like mentality. Otherwise the public will think rebooting your computer three times a day is normal and acceptable.

    I say this from the point of few as both a system administrator and developer. There were times in my old company I would highly object to certain courses of action because they might have compromised security. This forced the developers to go back and rethink things. However the developer side of me usually had a better suggestion anyhow.

    Which brings us to the next point, part of the developer "get it out the door" mentality involves a lack of understanding by said developers of how systems work. They learn their C++ or Java in school, but they fail to learn how the underlaying OS and hardware work. IT training has become job training rather then creating computer scientists. Perhaps things would flow better if all invlved better understood the fundamentals of computers.

    I for one am not said to see the development cycle slow down. Far too many times have I see bosses go, "Just get it done, we'll worry about cleaning it up later." Do you want the software controlling your car or the X-ray machine at the hospital being managed by such a manager? I certainly don't.
    • Re:Excuse me? (Score:3, Insightful)

      by ShadowDrake (588020)
      >IF we want the public to trust software and computers more we have to develop a more "engineering" like mentality.

      if engineering was like software engineering, you'd go into an architect's office, and say "great job on that suspension bridge. Whip up a motorcar engine for a universe where an electron is +5 charge"

    • not excused. (Score:3, Interesting)

      by twitter (104583)
      The days of slapping things together and getting it out the door are gone, and good thing, we all see what occurred at Microsoft when quality wasn't a top priority. Buggy software with huge security holes.

      You must not have read the article. The gripe list was all about red tape that does nothing for quality. All you do is deride a "get it out the door" mentality that has nothing to do with the legitimate problems the author raises.

      It's funny that you mention Microsoft, because 80% of the list has grown

    • by obtuse (79208) on Saturday December 06, 2003 @03:43PM (#7649206) Journal
      I agree that delivery of a mature stable system is the number one priority. Unfortunately this is often in direct conflict with the expedient goals of developers, who say things like "just give everyone access."

      The only real problem in the article is incompetent administrators and incompetent management. Interestingly there are no incompetent developers in his world.

      Delaying a multi-million dollar project is never okay for a competent admin. Competent management would never allow such a thing to happen either, or such an admin to remain employed. Missing backups should be an instant pink slip too.

      Unfortunately most developers are no more competent than most management and most admins. Most people are mediocre by definition. Paranoid admins are no worse or more common than managers who don't do anything but protect their fiefdom, or developers who know nothing but driving a particular gui.

      In technology we'd all be better off if we understood computer fundamentals better, but we can't all do that. Very few of my developers have any acquaintance with microcontroller programming, but studying that is a part of my understanding of how computers work. Most of them have never touched Unix, or any free tools either as far as they know, but knowing those makes me a better admin.

      Dealing with multiple administrators is a pain. Modern systems are large and complex, and complexity increases exponentially with size. You're going to have to deal with multiple administrators, and modern projects need a project manager.

      I worked in the office of the network architect for a fair sized company, and he spent hours at a time on calls making the network work, sometimes days. He also implemented a VOIP architecture that saved the company hundreds of thousands of dollars in the first year. None of the developers would have been able to do his job. They didn't have the technical expertise, nor would any of them have been willing to troubleshoot the global WAN around the clock.

      One director who wanted the NetArch to make a client's VPN to work right now, threatened to call the CEO because it didn't. Never mind that the client had refused to give us any of the information we had requested (weeks before) to make it work. We had done the best we could, and the final problem turned out to be one with the client's configuration, which we weren't given any information on. One client finally agreed to call their tech support, who pointed out that they needed to use a special acces point coming from NATted environments. Simple for them, impossible for us.

      A friend worked in a company without a dedicated admin. This startup full of brilliant coders got their FTP server cracked, and someone downloaded all of their work. Maybe it was one of their competitors, maybe not.

      Backups are a pain, and none of the development servers I've seen were actually backed up regularly by the developers. These were the same folks who insisted on running Visual Source Safe without licenses, and just didn't have an administrator, so when they had to fix the database or roll back to an earlier version so that people with Macs could use it, they were out of luck. They never bothered to learn to use their tools, so they encountered the same problems over and over again.

      When they wanted firewall holes for AudioGalaxy, or for me to give them software that they were unwilling to buy, or when they opened another virus infected email, I was at fault. When the dev servers failed, even though they existed solely to give the developers total control, it was my fault. When the VP wanted a deleted email back, we had backups though, unlike the development servers maintained by the developers themselves.

      I may sound cranky, but I was always cheerful & respectful of my developers. I knew that they just wanted to do their jobs, and didn't know how things worked.

      The author reports that many developers feel that administrative burdens are halving their development efficiencies. That's meani
  • Declare independance (Score:5, Interesting)

    by raider_red (156642) on Saturday December 06, 2003 @01:37PM (#7648287) Journal
    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.
  • by nbvb (32836) on Saturday December 06, 2003 @01:38PM (#7648300) Journal
    I'm not defending all the admins, because there ARE a lot of clueless ones out there, but have you ever stopped to think that we're here as subject matter experts?

    I'm a UNIX system administrator. My responsibility is to ensure my systems perform well. This includes actual performance statistics (I/O, CPU, memory), security, reliability, scalability.

    It also means I need to scale up the hardware as applications grow. I need to keep tabs on what my systems are doing, and why.

    I'm the "guy who gets in your way" because my responsibility is to the system, not to you.

    I don't work for you. I work for the systems. They are my "customers" if you will.

    Sure, I slow you down when I tell you "No, your app can't run as root."

    I slow you down when I make you diagram your database so we can lay out the I/O correctly.

    I slow you down when I make you tell me what you're doing with shared memory so I can tune my kernel.

    I slow you down when I ask for projections over the next year so I can plan the hardware and scale appropriately.

    I slow you down when I shut off telnet, ftp, r services, and every other plaintext protocol. You b*tch and moan because your expect script from 1994 needs to be rewritten, but too bad.

    I slow you down when I ask for a detailed list of which ports your application uses, who they communicate with, and what IP blocks I need to permit access from.

    Yep, I'm in your way.

    That's my job.

    And if you don't like it, well, too bad. I *DON'T* ask you why you're using C instead of Java. That's not my business.

    I'm a systems subject matter expert. I don't pretend to be a code expert.

    Your a coding expert. Don't pretend to be a systems expert.

    Let me do my job, and I'll let you do yours. We need to work *together* and understand the interactions between your code and my systems.

    Systems are NOT simple. They're very complex; you need to understand all the interactions here, from the kernel through the disk management (whether it be VxVM, LVM, or whathaveyou), through the network drives, through the firmware, through the HBA drivers...

    Let me do my job. Yep, it'll "slow you down" a bit, but in the end, we'll actually have a complete SYSTEM that functions. Code, OS, hardware.

    So you can't roll things out in an hour anymore. At least it works now.
    • by juuri (7678) on Saturday December 06, 2003 @01:46PM (#7648362) Homepage
      A common misconception amoung admins is that your responsibility is to the system or that the system is your customer. Unfortunately that isn't correct, you need to take a step back. Your customer is the "availability of the application/utility provided by the system".

      With that said, many programmers have no idea what is really involved with keeping up highly available large scale apps across entire corporations. As an admin you are responsible for tons of applications and functions being readily accessible, in many cases 24 hours a day. Just like you don't argue with the way they implement low level aspects of their code they should respect your decisions and choices when it comes to systems, networks and security.

      The linked article sounds like a case of having inept admins and assuming the rest of the world works like that. It was also typical in someone assuming they know what is best across every strata of a corporation.
      • Quite frankly, when people ask my what my objective is, it's a very simple one:

        "Don't get paged."

        My customer is the system, my objective is the availability of said system.

        Like you said, most developers have no idea really what goes on behind the scenes. They don't understand why building a cluster is difficult, let alone what quorum is, failure fencing algorithms and the like.

        They have no idea why it's perfectly OK for a cluster node to shut itself down, given the right circumstances ...

        But I digress
      • OK, first of all, I work both as a network engineer and a developer. There are great admins out there, just like there are great developers. Likewise, there are horrible admins and horrible developers. I don't think either group has a monopoly on excellence or ineptitude.

        That being said, The two jobs are really intertwined: admins should be contributing to the design stages of software just as developers should be keeping in mind deployment, administration and security factors when they're writing code. Sa
    • by Sanity (1431) * on Saturday December 06, 2003 @01:57PM (#7648457) Homepage Journal
      I'm the "guy who gets in your way" because my responsibility is to the system, not to you.
      No, the system is a tool, not an end in itself. Your responsibility is towards users of the system.

      I can't believe that even needs to be explained.

      • No. The original poster is correct. IT's responsibility is to the shareholders of the corporation for which they work (or the stakeholders of the organization if it isn't a publicly held company, etc.)

        If helping the users helps the bottom line, then you're right. If the users want to do dev work on a production system and threaten the revenue stream, then chopping of the user's genitals and hanging them on the door as a warning to others is the correct thing to do.
    • I don't work for you. I work for the systems. They are my "customers" if you will.

      Wrong. You work for the company (or organization--judging by your other posts, I suspect you're admining for a university, because you're cheerfully ignoring real-world business imperatives). Sometimes its more important to be first, to recognize revenue, to get "good enough" out there in the hands of users. Business pressures didn't disappear along with the dot.com boom. That doesn't excuse fundamental screw-ups, but y
    • People like you are absolutely the reason the BOFH stereotype exists. I'm really reeally glad I don't have to work with you.
  • Delicate Balance (Score:5, Insightful)

    by orangenormal (728999) on Saturday December 06, 2003 @01:39PM (#7648308)
    I my office, the IT personnel grant or deny software installation requests (among many other IT-related tasks, but software installation draws a nice example). People usually want software because it would make doing their job easier. Does this mean IT should allow any tool to be installed? If a software request is denied, the requestor will sometimes complain loudly along the lines of "Your job is to make sure I can do mine, not regulate it," to which IT will retort "but if we allow any software, it will result in incompatabilities between departments ultimately reducing productivity and increasing maitenance costs." Both are right; this sometimes results in a bitter relationship, but lets face it, they're keeping checks on each other. A successful development company needs to find a balance between the two.
  • by flinxmeister (601654) on Saturday December 06, 2003 @01:43PM (#7648344) Homepage
    For too long developers have been held up as the ultimate in computing knowledge, while administration has been seen as some monkeyboy sitting in a computer room swapping tapes out.

    As a result, nearly every end user of a developed system is given attention before system administrators and operators. The secondary result is SA's and operators are left with big piles of innefficient crap to wade through, and much of the pressure of making said piece of crap work. How many folks here have had to work in huge, bloated teams of SA's all to support an ill-concieved and poorly developed (but gee whiz does it look greeeat!) product, getting paged and phoned all night to come in an slap more duct tape? How many people here have had to manage a bunch of boot-camp MCSE's trying to do 400 manual processes an hour because "that's the way it was developed"? How many people here have had to explain to a customer that some piece of code written by a fresh off the MIS degree train VB developer isn't RFC compliant and therefore 45 percent of the people in the world won't be able to interface with it? How many SAs here have had to tune the crap out of boxes and networks because a login page makes 75+ ODBC database calls? How many security consultants have had to go in and basically tell a company that they'll have to repartition and reinstall every server because someone found SQL injection in an app that required superuser privileges?

    The list goes on and on. Administrators aren't there to make life easier for developers, they are there to make things work--and make them work better, more reliably, and more securely. I'd suggest that this whiny ivory tower developer wake up and realize that coporations have gotten smart to the crap he's been turning out and further realized that the people who run the stuff are just as important as the people who write it and use it.

    In short, he needs to learn how to work on a team.

    Developers are smart, but they aren't the top of the computing pyramid. There are many other groups of people that are just as smart in different areas.
  • IT Differences (Score:5, Informative)

    by jdhutchins (559010) on Saturday December 06, 2003 @01:47PM (#7648374)
    There are a world of difference from what the normal marketing person, executive, etc needs from a computer and what a programmer needs. Most people don't need much in the way of room to play around, and they shouldn't have that room.

    Programmers are different. I write code, I need to test it. Maybe it needs root to run. You, as the sysadmin controlling my stuff, need to let me do that. In reality, there almost needs to be a different network for programmers, where they have the room that they need to mess with their code and see how it works. Sysadmins need to understand this difference. Programmers don't need root access to the network's servers, but they might need root access to a testing server, and it's the sysadmin's job to make sure that he can have a testing server running on a network.
  • by SuperBanana (662181) on Saturday December 06, 2003 @01:48PM (#7648379)
    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

    Nice mindset there; you're a real team player. The reason we are there(network/sysadmin here) is to HELP you.

    However, we're also there to make sure you don't do stupid things. While you say "these IT people get in our way", I point to a laundry list of really, really, REALLY stupid things developers have done at every company I've ever worked for; they just don't THINK about anything besides code, and they get Great Ideas without thinking through the consequences, either technology or business-wise. Some of it is just sheer laziness, and I've been faced with developers who act liked goddamn 5 year old spoiled rotten BRATS- this was particularly bad a few years ago when anyone who knew what "printf()" meant, got a 75k+ job.

    Prime examples of stupid things I've seen: logging into machines using the root account because you're too lazy to use su. Or not allowing you to ssh directly into a system from your home PC without a VPN. Or yelling at you when you use temp tablespace for permanent data. Or not letting you move production functionality to some desktop system underneath your desk. Or using the database admin account for your application, instead of a seperate account?Or not implementing your latest code changes until you're willing to put down on paper that you actually did your job properly and TESTED the damn changes(do you know how many times I've seen developers just push code out without testing? Guess who gets blamed first. Guess who gets PAGED first, at 3am when it crashes. Management doesn't distinguish between a misnamed variable and a "Internal Server Error 500"; they're both production problems, and you're not in charge of production).

    We're part of the team, and we're here to stay. You can either work with us, and clearly communicate to OUR supervisors(not just us) what your needs are...or you can make us the enemy, always try to do things half-assed, and get nothing done. Your choice- but management usually sides with safety, and we're the ones saying "that's not safe", and even if management doesn't side with us- when things blow up, we simply point to the emails we sent saying "that wasn't safe", and let you sweat it out while we restore from backups and clean up your mess.

    Sometimes it's simply not our choice; it's "do it this way, tell Development that". You have no idea how frustrating it can be sometimes for even us- I once worked at a place where root passwords were changed on us sysadmins, and we were told "use sudo". The incompetent assholes a few levels up didn't realize that gee, guess what, if the machine crashes and fsck fails, you need the root password.

  • by The Welcome Rain (31576) * on Saturday December 06, 2003 @01:51PM (#7648398)
    On the one hand, I can understand the frustration of developers who have been arbitrarily undercut by surly, inefficient sysadmins. I've been there. A lot. On the other hand, the author of the article mentions at least one case in which he probably deserved to lose: software licensing. I'm glad you can deal with an InstallShield, bud, but that doesn't equate to knowing the terms of a license or how it will affect the company. And the fact that you don't acknowledge this issue suggests that you shouldn't be allowed to make such judgment calls.

    Yes, we developers are a sanguine lot, continually making risky improvements with blithe optimism that they will work and actually improve things. And on occasion we are disastrously wrong -- that's what test systems are for. However, that's no justification for making it impossible to do our jobs.

    After all, it's not as if most sysadmins are competent to pass judgment on our proposed changes. How many times have you heard an admin claim that he went into his line of work because programming was too hard? The odds are that his problem was with thinking things through and designing them carefully. In fact, most sysadmins do not appear to appreciate the basic concepts of scalable design, code reuse, or even revision control. And this is who wants to vet my software changes? No wonder they take all year -- they're too stupid to understand them.

    If you do employ an admin who can do all of these thigns correctly, hold onto him, whatever he costs. Treat him kindly. Make his life as easy as possible. He is a rare specimen.
  • by fw3 (523647) * on Saturday December 06, 2003 @01:52PM (#7648408) Homepage Journal
    Jezuz I haven't read such a pile of crud in ages.

    Are there sysadmins who've never coded, not highly skilled at what they do who are a drag to work with? Of course. Sysadmins run the gamut, the best (and probably most productive) have enough coding experience to know and work with the dev side also. The very best can run circles around the average dev imx. Naturally the very best devs are int the same class.

    There are just as many 'developers' who don't have the first idea how to perform adequate testing, let along consider the constraints of running in a production environment let alone writing portable, consistent or maintainable code.

    The author of this article is quick to bitch about a sysadmin losing his working files. Sure it happens. What the hell is with a developer who doesn't bother to keep any working copies of 2 weeks work? (In my own time managing a corp. network I'm pleased to be able to say I had exactly one instance of unrecoverable data loss -- where two users hadn't realized that NFS did not provide pc clients with any form of locking)

    As a distribution maintainer (lunar) [lunar-linux.org] I see several OSS packages a week breaking reasonble build schemes or changing thier tarballs, (breaking MD5/PGP checks) without updating version info. So I'm sorry but there are no shortage of sloppy developers out there.

    In my own engineering practice I've found over the years that all work goes better if the people doing it know they'll be held accountable for it over the long haul. Too many devs are allowed to get away with a 'throw it over the wall' mentality, going on to the next project and never having to deal with some of their cruft. Of course the same logic applies to the sysadms, I've seen lots of the behaviors the article rants about it but I gotta say ranting and pointing fingers ain't the solution.

  • by Necron69 (35644) <[jscott.farrow] [at] [gmail.com]> on Saturday December 06, 2003 @01:53PM (#7648419)
    I've been one of those evil System and Network administrators for over a decade now. Most of that time has been spent supporting software development labs.

    I don't know what planet you or the author of that article live on, but I've seen a steady increase in the quality of software development and maturity in the development models used in the last decade. This may have slowed our development a bit, but you can see the results in our defect find rates. We're delivering a much better product than we used to.

    Rather than just hacking out some code, doing a perfunctory test, and throwing it over the wall to be released, our developers are actually managed these days and do this cool thing called "planning." Yes, they actually investigate, propose, design, implement, and test code on a schedule. We even have teams dedicated to testing the systems to make sure they work. Oh, the horror!

    In a decent software lab, which I consider mine to be, most of our management is also made up of engineers who rose through the ranks. These people know their stuff and trust the engineers beneath them.

    In my area at least, we've also seen a large increase in the complexity of systems as well. No longer are our engineers programming a lone application to slap on a PC or a server. Our projects are large and distributed across multiple networks and servers. We have to traverse firewalls and worry about security trust domains and lots of other things that nobody cared about a decade ago.

    I think that this increase in complexity of projects is likely responsible for the entire list of negative consequences that the article attributes to 'role fragmentation'. The only one I'd leave out is "de-skilling of the workforce". That may have been true in 2000, but the layoffs of the last few years have forced everyone to do work that was once done by multiple people.

    All of that requires more attention to detail, and requires more effort to get right. I don't see that as good or bad, it simply is. Get used to it and stop whining about having to actually plan something and coordinate with others.

    - Necron69

  • by Monoman (8745) on Saturday December 06, 2003 @01:53PM (#7648420) Homepage
    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.

  • by pirhana (577758) on Saturday December 06, 2003 @01:55PM (#7648429)
    I know I am going to get modded down terribly for this. I dont care. Because this is my sincere opinion. I want to ask these average americans who bitch about outsouring , what is wrong with outsouring ? its part of globalization which is something america initiated, perpetuated and benefited MOSTLY. Giant american multinational corporations went and screwed up virtually every local industries and firms in developing countries. As a result of this american economy benefited a lot(whether it was just for a few rich or not is open to debate). Heavily subsidized american agricultural products resulted in devastation of un-subsidized farmers in the developing countries. All these time, these guys who bitch about outsourcing were happy with these. But when the same trend of globalization continued and resulted in so called "outsourcing" , all hell broke loose !!!. So where were you all when a HELL LOOOOT of farmers and other industry workers in developing countries like india were loosing jobs becoz of globalization ? Or is it that "anything is OK as long as we are at the receiving end" ? Why there is a hypocrisy when its outsouring ?
  • by Sevn (12012) on Saturday December 06, 2003 @01:57PM (#7648450) Homepage Journal
    No truer words have been said.

    They need to wake up and understand that us developers are the true brains behind the enterprise. We walk on water. We are GODS I tell you. I can't count the number of times I've had to yell at my sysadmins for making the coffee too strong, not popping grapes in my mouth fast enough, or moving the hand-fans too slowly. The fuckers. It's as if they don't understand that their purpose in life is to serve me. That the entire company exists not as a profit generating entity, but as my personal support system. Heaven forbid I do something smart like suggest or create a decent PROJECT LIFE CYCLE to avoid conflicts with other departments. I'd much rather whine on slashdot. Now I have to go. My 3 o'clock rubdown is coming up and I need at least another 2 hours of slashdot reading time before that. I mean christ, what do they pay me for.
  • by rob_from_ca (118788) on Saturday December 06, 2003 @02:00PM (#7648478) Homepage
    This article has some of the symptoms right, but it's got the root cause wrong. All of those things mentioned are problems caused by poor quality administrators (or just as often, poor policies that the admins have no control over).

    Just as low quality developers with no sensitivity for production issues cause problems for talented admins, low quality admins with no knowledge of development cause problems for the developers. Talented administrators help your development team build bad-ass production ready apps and don't get in your way.

    Mostly though, it's IT management and corporate higher ups that have created this sprawling bureaucracy, for a variety of reasons. The admins would love to change it, but really have no say.

    As with anything, hire talented people and things will run more smoothly (as long as you don't shackle them with process developed by and for the untalented people :-) ). The best sysadmins are those that understand development and the best developers are those that understand the production environments.
  • by xyote (598794) on Saturday December 06, 2003 @02:01PM (#7648487)
    Actually more like 16, and then switched to sysadmin (which was supposed to be temporary dammit! WTF is it with the only last job counts as far as skills go). Most progammers have no idea what is involved in system support. It's a major pain, which is why I've been trying to get back into development. Trying to explain to a user why something isn't as simple as when they just fool with their own machine is equivalent to a programmer trying to explain to a non-programmer why a quick and dirty script isn't generally applicable. You have to do error checking, make sure it applies generally not just specific cases, and is thoroughly tested. Same thing with system administration. You have to figure out how to make something work for all users, and above all else test the hell out of it before rolling out the change. Last bit is important because unlike programmers, sysadmin customers know who you are and how to find you if something goes wrong.


    And yeah, there are BOFHs. Even sysadmin run into them themselves if the organization is large enough.

  • by Ridgelift (228977) on Saturday December 06, 2003 @02:02PM (#7648501)
    Why has the administration been allowed to bloom unnoticed in the software industry when it is having all these negative effects?

    Because Administrators are the ones who have to deal with the most headaches. I quit administrating and switched to development because of the complete lack of control I felt. The bulk of my admin was on Windows NT servers. A bad patch or rogue program caused grief, which I was expected to fix. Because of largely closed-source development environments, that meant flailing around in the dark trying endless shotgun approaches: patch, reboot, test, change, reboot, test, reconfigure, test, blow out OS, reload, test...on and on and on. Meanwhile developers would say "just get my database up and running! I don't care about _your_ problems".

    Unix is the best environment I know for Administrators. It slowly nudges them towards programming because of the close relationship of scripting and automation. Admins grow to become programmers. NT on the other hand, is a completely non-sensical environment because it's prodiminatly adminsitrated through application layers; no programming knowledge required.

    The old addage of freedom and responsibility applies. The more responsibility you have, the more freedom you should have. The less responsibility you have, the less amount of freedom is tolerable. Since a lot of admins work with closed-source products, they do not have the freedom to fix or investigate problems the way their open-source counterparts have, and therefore are given the responsibility without freedom.

    Largely, I agree with the article's points, but I think the blame goes beyond the administrator. I think it belongs squarely in the lap of the commercial software industry. Then answer: open-source.
  • by RalphTWaP (447267) on Saturday December 06, 2003 @02:08PM (#7648539)
    *ponders*


    ClearCase is another one of those products where the behaviour is not safe. For example, if you find that another person has checked out a file, then you can check it out "unreserved". When you go to check back in a large batch of files, it checks them all back in except for the code that was unreserved (it's that remembering state thing again). So the net effect is that the code under source code control can't compile. CVS is free and has this facility: why should we pay a premium to make our code base unstable?


    This overly general statement kills the article for me. I have the pleasure to use a superbly-maintained clearcase system daily (no, I'm not the administrator, just a happy customer), and must disagree. So I'll do so:

    "ClearCase is another one of those products where the behaviour is not safe." The author has mentioned one other version control system at this point in the article, and specifically states that it was an administration problem which made the system unsafe. Perhaps revision control systems _are_ database systems (yes, yes, they are), and like other complex databases deserve a competant administrator.

    "For example, if you find that another person has checked out a file, then you can check it out 'unreserved'." First, if multiple people are working in a Clearcase environment, and they are working on overlapping or dependent file sets, then they should be working on different branches from a known label point on an integration branch, only use that deviates from this best practice would ever find that a file was checked out by another. In addition, 'unreserved' checkouts require that the file be merged when it is checked in with changes, if the developer can't create the merge properly, they shouldn't have checked the file out in the first place.

    "When you go to check back in a large batch of files...." Why would you have a "large batch of files" checked out to begin with? Correctly structuring your branch structure allows each developer to make multiple check-ins as they work, providing not _just_ named-version tracking, but also fine-grained control (Ever wished you could back out that change you made just the other morning, don't remember what you did before? Use a well implemented version control scheme). Again, blaming what seems to be poor setup and management of your version control system is hardly the answer.

    Certainly, there are complexities to working with a version control system, a system that maintains both position in the directory structure and versions over time deserves competant setup, administration, user-instruction, and users. If those are missing (and it seems that they are in the author's situation), then head back to the luddite's favorite method: "foo.c.1"
  • by visionsofmcskill (556169) <vision@getmp.PLANCKcom minus physicist> on Saturday December 06, 2003 @02:10PM (#7648553) Homepage Journal
    This guy spends most of his time crying about people doing their respective jobs.... if you look closely ... he is essentialy arguing that all these admins should basicly be working FOR him... UNDER him.

    He believes the Database admin should allow him to make any changes whenever he wants them.... who cares if theres a REASON there are naming conventions.... never mind that someone actualy took the time to think about the possibilities of portability, or that there may be software already developed elsewhere that is dependant on those conventions and may need to be portable or cross-aplicable.... never mind how your changes may one day end up going live with a horrid architecture that you "evolved"

    He percieves security and network admins as simply being in his way, and that having his rights restricted is not only an insult, but an offense to his craft. Not minding that security holes can and WILL bring a network to it's knees... expecialy if your a target.... not thinking about the huge potential for corporate espionage, or employee sabatage. Maybe i should just give you full rights to the entire domain?

    He thinks that having the "right" to install whatever he wants whenever he wants without respect to the company policies or threat assesment is a given. That the potential for harm in HIS case is somehow different than from the secrataries.

    Well to you sir i say this..... get your head out of your ass. Unless your specificly developing an application that uses communications systems outside of standard FW blocking.... there is no reason on gods green earth that FW shouldnt be locked down as much as is possible. Have you ever seen what a virus can do to a network? What Blaster or sobig did last summer? while blaster is preventative by those "pesky" vigilant admins, sobig can bring a company to it's knees without even getting infected. My T1 maxed out on incoming sobig eails sent from the web..... because some jack-asses in other companies and home users werent so "strict" about their own security measures. I almost lost my job because management coudltn understand that the problem wasnt even ON our network.

    I have also developed... majoring in computer science and working on several large projects. And box control is somewhat necesary for programmers.... but in the long run.... really isnt. you set up and request a bunch of tools, install them and should be through on that machine. If you want full out control.. your not gonna be on my network, no fucking way... cause salespeople, secrataries and smart-assed "developers" catch nasty viruses and cause serious problems. sometimes i hate laptops.

    He does mention some very solid points, all of them relating to BAD administrators. Admins who dont evaluate the potential benefits of suggestions by their co-workers, admins who fear for their job fruitlessly, admins who think they are god of their systems and allow no flexibility, or admins who arent willing to do something as simple as setting up test-bed networks DMZ'd away.... or on a seperete network entirely. These guys suck, which is why i have three pipelines to the net... so when users need to do things i feel are in-secure, or when we recieve visiting salespeople and/or outside computers.... i can safely give them web access without it touching my network.

    It's called team-work. And the biggest problem with this guy is is he obviously thinks he is the most important part of the company... like everyone should be catering to him.... well guess what? your not that important. And in 90% of buisnesses out there, you barely exist. Most comapnies have a primary need to maintain their systems, and to improve them safely and incrmentaly, because any failure, even one day of outage... will cost far more than your extra time spent dealing with the granted quite annoying delays of a secure and well-managed infrastructure. the day to day cost of my companies development team (fairly large) verses the cost of having any sort of network failing on any particular si

  • my reaction (Score:3, Interesting)

    by register_ax (695577) on Saturday December 06, 2003 @02:10PM (#7648560) Journal
    Once upon a time, developers were promoted if they had the stomach for Gantt charts and paperwork. The engineers delivered functionality to the business: there was a clear power hierarchy. If you were lucky, you had an administrator who did exactly what you asked, and kept the systems running without imposing on development.

    This was a time when innovation ran rampant. Every business in the industry was trying to capitalize on a brave insight into how the future would be governed by this "tool". It was a period of risk and reward. The "administration" saw this as the period of growth or the techies were in fact the administration.

    Today it's a very different picture. Your typical IT director in a large corporate is surrounded by an entourage of software administrators. It was interesting listening to a famous British filmmaker (David Putnam) comment on how the gaggle of administrators surrounding Hollywood stars tried to make them as paranoid as possible about needing their administrative skills.

    The time where computers were an innovation in and of themselves are long gone. Computers are now a tool to create innovations rather than being an innovation. This process is like building houses. Sure you have some design, but most of the innovations have to come from new material processes whereas the builders are now the ones that simply follow the rules. Programming has become a commodity where the US doesn't follow well. US based business wants to drive a profit and as a result, doesn't surprise me one bit jobs are going to where it will drive profits higher. The dot-com bust was exemplifying this in some way. They were trying to build a basis on this notion that simply just doesn't hold true. Look at what is now becoming successful (relatively). People in other areas are becoming educated and performing our "textile" work.

    Today's world is "a very different picture", but it isn't the result of managers "lost understanding", only a paradigm shift that proves beneficial to the end result. Emphasis has been dropped.

    And finally to address the situation in development that is still happening in the US, poorly. It isn't just seen in this field, but all. I think the US is largely beauracratic. The US's stance is on innovation where it can drive profits. This is something that happens to all markets to stabilize a product. The New New Thing [amazon.com] exemplifies this somewhat. Not that the book, although features Jim Clark, Netscape founder, is not technical, but only works at accentuating Jim Clark's abstract persona. But whatever.

  • by enjo13 (444114) on Saturday December 06, 2003 @02:32PM (#7648692) Homepage
    I see that the legion of Slashdot Sysadmins gets up earlier than I do:)

    The problem for me is actually not the system administrators. While they often have rather insane network policies and restrictions (that's a whole other Slashdot thread), they don't tend to impact me as a developer.

    The bane of project development are the managers that are 'above' me on the corporate food chain.

    My current job is a perfect example. When I began looking for a job, I purposely avoided big companies due to prior experience. The company I worked for started out quite small (I was the 5th employee I beleive), and was quite succesful. Our design tended to be fairly solid and we could move much faster than our competition was able to. A particularly memorable example occured when both ourselves and our primary competition (~40 employees on the project) began working on an identical feature. We delivered it in 3 months, they took a year.

    Then we where bought up by a medium sized corporation, good benefits and they left us alone to keep doing what we do. That was great. Then we started dealing with larger companies who wanted to use our software. They came by and visited the company and decided to impose their corporate culture on us. Contracts required us to have a project manager, Q&A manager, etc.. The small company grew.

    Now my days are spent rationalizing design decisions to my project manager, keeping the Q&A manager 'in the loop' to prepare for upcoming releases, and basically distracting myself from what I do best... develop software.

    The point being, that the project management functions and Q&A functions where handled very well before the arrival of these new people. Our software was generally solid and delivered months ahead of time. The addition of these extra layers of administrators and managers turned an incredibly efficient company into a horribly inefficent one. We recently missed a delivery date for the first time since I've been here, and now our corporate owners are sending in MORE management to 'fix' the problems that 'they' created. Sick.
  • by Shoten (260439) on Saturday December 06, 2003 @02:34PM (#7648712)
    What the article entirely misses is WHY there's role fragmentation. My girlfriend works in the IT department of a large law firm, and she's tasked with one thing: the implementation, testing, and rollout of a new document management system. And it's a full time job, for months now. Part of it is because they're adopting the latest and greatest version of the product, but part of it is also just simply because the software needs handholding to get it working correctly. There are bugs, nuances, and various sorts of tuning (the web component doesn't work correctly if you keep your browser W3 standards-compliant with regard to number of concurrent connections, for example.) It's not like the admins got together and said, "Let's make this software really manpower-intensive to install so that we'll all have jobs!" The developers have written this stuff that way, although obviously not with that end in mind.

    In the end, if there need to be so many admins, it's because the software demands it, not the other way around. And I tend to think admins are pissy because developers are increasingly giving them crap to administer.
  • by qtp (461286) on Saturday December 06, 2003 @02:49PM (#7648825) Journal
    is in the first paragraph of the article:

    PC developers doubled up as administrators,

    but it seems that the author missed several of the intervening years that have led to the current situation.

    In the beginning, the developers also were required to administrate the machines they were developing on and for. Shortly after that, as there were more deployments, there were folks who's primary task was system administrator, and they would perform development tasks according to the needs of the organization and in order to make thier own jobs much easier, then came the network administrators, who would also develop software according to the needs of the org, and in order to make thier own jobs much easier. Then it all went to shit as the marketing department realized that there was money to be made, they began asking for needless software with dubious need and poorly thought out devlopment requirements that could be used marketing fodder. The administrators became notorious for (rightly) defending defending thier turf and saying "not on my network. not on my system."

    So the role of developer was born, a person with skill in writiong code with the willingness to write program asked using whatever programing language specified without any objection whatsoever, regardless of the technical merit of the spec, the need for the program, or the overall effect on the system, as long as they were paid. All applications were written in whatever the language of the day happened to be, and fufilled the purpose of whatever the flavor of the month dioctated. What had been elegantly designed systems that specifically fufilled the needs of the user using existing tools (most often transparently) whenever possible, using custom (or community) designed software whenever necessary, and requiring the least amount of system rescources possible, now became incomprehensible morasses of rediculously complex dependancies, multiples of propietary protocols that replicated each others capabilities but were "incompatible" with systems that served the exact same purpose, huge collections of libraries all addressing the same needs and differing only in what would justify the high cost of the (propietary) product, and an absolute disregard for any sense of of efficient and elegant network, system, or application design.

    The design process has been divorced from the persons who use the apps, maintain the systems, and have the best knowledge of the needs of the given organization. Software development is now managed by sales people, marketing divisions, and corporate executives, most of whom have little real knowledge of the IT feild other than what they read in Gartner's artcles, and will accept the advice of a "consultant" before even considering asking one of thier own employees. These are the people who believe that the best developers are teenagers, that ".net" is the "way of the future", and that when a sales person tells him that thier product achieves something never before accomplished, or that it provides capabilities available nowhere else, they believe this.

    Now the developers are crying that they don't have domain administrator rights on the network, or that they cant write to directories that they have no reason to be writing to in the first place. They bitch when the network has been infected by yet another virus, but complain when the administrator strips all VB script attachments from thier emails. They bitch about how much work they have, about thier hours, and about thier pay, but drop to thier knees for any manager that brings them yet another impossible to implement product idea or project that serves very little purpose (other than as something that might sell). They bitch that the admins are fscking around all day without understanding that this means all is well on the network and the admins have done thier jobs well.

    This is the problem in the development world, and it is being addressed by Open Source. True, there may be some job loss a

  • by FearUncertaintyDoubt (578295) on Saturday December 06, 2003 @02:50PM (#7648829)
    It sounds like he is facing situations where there are too many administrators for the size of the project. It is very much a matter of balance. If I am developing a system for a 5-workstation small business, I can be network admin, DBA, help desk, developer, and even trainer. It probably would be unnecessarily complex to bring in separate people for each task (though consulting firms love to load up lots of extra people on projects).

    However, there's a real need for administrators, and increasingly so, as the systems get bigger. I'm the lead DBA for a app development staff of 25. Do I get off on holding the keys to the databases? No, but we ran for a long time with developers as sa. The bottom line was that there were a lot more problems than there are now that I locked the dbs down. I also realize that that puts a greater burden on me to not be a bottleneck in the development process.

    That said, the problem is not in the fact that you have administrators, it's that you sometimes forget what your role is. Developers forget this all the time, that they are supposed to be responsive to users. Administrators forget that they are supposed to be responsive to users. Customer service forgets that they are supposed to be responsive to customers. I have to occasionally step back and remind myself of the fact that I am there to support the developers. But to think that this is only something administrators are prone to is to try to single them out as being exceptionally sinister. It's just human nature, and we all have our way of sometimes screwing the people we are supposed to be helping. Contact your local congressman for more details.

    Every day, I spend time configuring the system and developing policies that give the developers the greatest freedom possible while maintaining stability. And in general, the developers appreciate the effort. Why? Because each one knows that, while he is sometimes hindered by my policies, he benefits greatly by everyone else following them. And therein lies the whine of the selfish developer. He wants everyone else to follow the rules to make his life easier, but he doesn't want to follow them himself.

  • by 3ryon (415000) on Saturday December 06, 2003 @02:56PM (#7648877)
    I inherited support for a corporate document repository a couple of years ago. This system was written in-house, and completely built and managed by the developers.

    Here's a quick idea:
    Server was floor standing in a wiring closet at the location the developers worked in. Not, in a rack at the corporate data center (with redundant power, switches, etc).

    The server had 10 (!) 100BT NICs. They were all teamed and run into a 10/100 hub on the floor that then had one uplink at 10BT.

    Server had a very nice 6 channel RAID controller that was completely unused. Instead the hard drives were connected to the internal SCSI and software RAIDed.

    Moral to this story: Yes, developers and admins should work together, but each should respect the other in their field of expertise. If the admin tells a developer something is a bad idea, they probably have a reason for saying that.
  • by Spoing (152917) on Saturday December 06, 2003 @02:59PM (#7648895) Homepage
    I've noticed that 5 years ago, someone was always designated as the CM. Now, nobody is.

    Maybe the problems with keeping development, deployment, and systems administration in sync would be helped by that level of glue.

    The result would be that the fragmented systems administration level would be simplified since they wouldn't have to deal with configuration issues except where they impacted ... well ... systems administration.

  • by SoupIsGood Food (1179) on Saturday December 06, 2003 @03:06PM (#7648944)
    I'm a little touchy on this topic, because I used to be an admin in a cross-platform Unix shop. I was let go when the money got tight, under the exspectation that the developers would take over my position in their spare time.

    Three months after I left, they had to hire two admins to replace me. (One for Sun, HP and Linux, and another who could handle AIX, AS/400 and the mainframe development system.)

    Administrators do a lot more than sit on their ass cruising slashdot. Capacity planning, filling out purchase requests for everything from extra ethernet cords to $85,000 Sun Ultra Enterprise mainframes. When that stuff shows up at the front door, it's the admin who plugs in the patch cables, and OS's, configures and installs in the datacenter the Sun. This is all time developers could be coding.

    What's worse, many of them just didn't have the skill set or the mindset needed to be an admin. Rotating the backup tapes of the NFS server is second nature to an admin, like getting that first cup of coffee in the morning. Yet it wasn't done after I left... not one of those 50 programmers thought to do it. So they lost a month's worth of work. (They also didn't offsite the backups.)

    It took one guy a week to figure out how to change the network configuration on an AIX box... a week he could have used to work on revenue-building product. (He didn't even know about SMIT, but wrote a half-assed startup script using IBM's wonky AIX system commands.)

    This was in a tiny developer... maybe 50-60 coders and QA'ers. The picture changes even more dramatically when you are trying to write software to fit into a huge IT infrastructure.

    The reason why there are so many different kinds of administrators is because there's simply too much for one guy to do. Most developers don't have the mindset or the skillset to manage a 24/7 computing environment, and they sure as hell don't have the time.

    There are =some= developers who can install DB2 on a Windows box and keep it concurrent and compatible with DB2 on the mainframe... or even realize there are serious differences between tthe versions of DB2... the author isn't one of them. Even if it's developed on the PC, it will probably be deployed on Big Iron if the project takes off. Understanding that requires experience and an understanding of how all these marvellous toys are going to be deployed in the enterprise.

    Basically, the problem the author has with his development environment is that it's bog-standard corporate... Microsoft products on personal computers and workgroup servers, and big boxen in the back room running Java.

    While it would be nice if the company would buy you a PC and a database server, gave you a network connection and said "Go to it!", that environment wouldn't produce software that works with everything else in the system, or worse, would introduce instability and dataloss.

    Virii are a problem if you use a microsoft platform, whether you're a 1337 coder god or Larry in Accounting. If you need exceptions to standard corporate practice, that's something your manager should be dealing with the IT staff with. (And the IT staff, admins and their managers, all the way up to the CIO, should plan on and quickly implement exceptions to policy when needed. But that's another rant.)

    SoupIsGood Food
  • by Featureless (599963) on Saturday December 06, 2003 @03:35PM (#7649158) Journal
    Disclosure: I'm a long-time developer. I have often worn both hats. I have also in the distant past been an administrator.

    I read this guy's article, and I feel his pain. He is clearly suffering in a bad corporate environment.

    What he has done is scapegoat administrators, when what is happening is not a problem with administration, but with senior management.

    When there are too many administrators, when they are not doing their jobs well, when they are deploying bad tools, when they are poor communicators or worse, obnoxious... when, overall, policy is bad, and the work environment is imperilled, look up, my freinds, to the head office. The fish rots from the head.

    The idea that administrators might be a "problem" is novel just because normally in a bad shop with failing senior management you just get bad developers... bad everybody. Because hiring standards are shit, because bad behavior and bad performance doesn't get anyone fired.

    I actually do see specialization as a problem - but as an unavoidable one. As our work has grown in complexity over the years, specialization was inevitable, and we are just seeing the tip of the iceberg. But let me speak from the vantage point of a relatively well-managed shop. Here is what work is like for me.

    We do have an IT group that "runs the desktops," making sure email gets delivered and wrangling windows and fileservers and so forth. They lock down the machines of quite a few people, but they are flexible and friendly - and developers (and anyone else who has a need) get full privileges on their own machines, and even on development servers if necessary.

    Our backups run, consistently, on time, and well.

    We have a Unix ops team (that encompasses our DBA) that is 2nd to none in my experience. They will ride your ass hard for anything you want to do in production - as they should. It's their ass if those machines go down, and that 2nd set of eyes has caught many a terrible thing before it escaped our development and staging environments. When we are testing something for scalability, they are in there with us, unleashing Solaris or Oracle wizardry, literally coaching better code out of developers, and generally making magic happen.

    That in itself is a good snapshot of specialization working as it should - not insular, but aware of what's on the boundaries of what you own, and working as a team.

    We have a complex security architecture that simply works. They don't make semi-montly changes to it, because they did it right the first time. DBA staff is a collaborator in your database design - my god, I can't imagine these people holding _us_ up. Its almost always them waiting for us to carry our leg of the relay race.

    Our long-suffering QA department is strikingly overqualified and polite to a fault when we destroy their schedule and then ask ridiculous feats of endurance from them. Even when they catch some pretty dumb stuff on our part, which they do quite often.

    We use good tools, often open source, but not out of doctrine - our choices won on their merits. Management is ready to throw out anything if it doesn't work. We are platform and vendor agnostic - advocates and zealots get put in their place.

    We are very productive, and although we are far from perfect and are not all of us dream-team members, we do extremely good work. Our company is so spoiled, and I think many who are relatively new have no idea how lucky they are.

    And why is all this? One simple reason. We have a good CTO, and he's hired and promoted middle-management who are good engineers. And that, pretty much, is all it takes.

    The trouble in big companies is that you have absentee management who pick senior technology leadership without any sense of how to gauge talent, and pay no attention to their performance, almost literally until (sometimes even after) it has burned the company down. The old white men are by and large still prime representatives of the previous generation in terms of their ignorance of technology, and every generation's aristocracy has the same habit of being in flight over the Swiss Alps while the house is on fire.

    One man's opinion.
  • by Bob9113 (14996) on Saturday December 06, 2003 @03:35PM (#7649160) Homepage
    There seem to be a lot of admins here who are missing a point he implies early in the article, and which he does not sufficiently amplify:

    I understand that those DBAs who understand the details of the database engines are worth their weight in gold.

    My impression is that he is not talking about the sort of admin that is likely to be reading Slashdot on a Saturday. He should have repeated this statement in each section, to make it clear that there are good and valuable admins in every sector.

    It is my experience that we are now 60% over-administrated.

    This is also a bit too understated. He implies at a few points earlier in the article that he works for large enterprises. If you've worked in a large enterprise, you know that in such places, the paper-pusher admin to skilled admin ratio is 60/40 on a good day, going downhill, with a gale-force tailwind.

    The people he's attacking are (for example) the sorts that engage in "security by chewing through the wires" - putting a firewall at every major network nexus, shutting down all traffic, and demanding written justification and properly red-tapified authorization for every open port. Don't get me wrong - default deny at the perimeter is a must, and default deny on some nexuses is the right choice. OTOH, for example, a default deny firewall between the developers and the appservers has a very real cost (EG: waiting six days for paper to clear before being able to turn on JMS). He's not even saying this cost can't be justified - he's just saying that cost has to be assessed and charged to the administration budget, and it is currently charged to development:

    the true cost of administration must be accounted for when totalling up the cost of any project.

    The point he's making is not that administration is bad, but that because management has lost it's grasp of development, and because they can grasp the paperwork-and-authorization oriented style of administration, management has given administration more power than is optimal. There's a balance that must be struck between wild-eyed developers and stodgy administrators - safety and speed are both valuable, and they are naturally at odds. In major enterprises, the balance is askew and getting worse, because the practice of software development is evolving so rapidly. Likewise, administrators are quick (and right) to point out that in smaller companies the balance is askew in the other direction.

    I think his main point is that bad admins are a bad thing, and that management often sees bad admins as good admins, because bad admins generate more sturm und drang. "If people are complaining about things being shut down, there must be some security goin' on. If they're not complaining, what did we hire these guys for?"

    So unruffle your feathers - if you're not allowing your developers to host outside accessible websites on their desktops, he's not talking about you.

    OTOH, if you don't know enough SQL to understand a script that has been submitted, and you reject it because it is not indented properly, remain ruffled - you are the problem.
  • by Eskarel (565631) on Saturday December 06, 2003 @03:38PM (#7649175)
    Ok, firstly I've done some development and some administration work so I know a bit about all of this from both sides.

    1) The list of so called administrators here is ridiculous, you can't include network/system administrators in with package vendors(what ever the hell they're supposed to be) or blame the whole thing on J2EE because it has architecture problems, that's not admins fault. As a side note, forcing developers to do things they don't want to(document code, plan before they start etc) is a necessary evil since most coders including myself don't want to do these things.

    2) The idea of developers doing their own administration is to be honest laughable, if this guy thinks that administration slows down development imagine what it would be like if the people who were supposed to be coding were doing it, even if it didn't take all their time they'd be focusing the results on their needs not on the needs of the secretary next door.

    3)As for getting root permission on anything or being able to install your own software. Being able to code does not make you qualified to run a system even an internal test system(assuming you want it connected to the internet). Even on a windows box giving root access to anyone(even developers) can be a serious nightmare. In my experience fixing the computers of people who know something(ie developers) is much worse than doing it for people who don't since other than the usual crap they don't futz with their pc's much. Supporting a machine with random software and random configuration is hard enough when it isn't mission critical, ask tech support.

    4)As for Roaming profiles, the reason people set them up is because that way, when you hose your machine(which 90% of people will do either because of ignorance or bad luck) they can just roll you out a new one without having to recover the data from your old one.

    That said any system administrator who tells you "it's only two weeks worth of work" under any circumstance beside an act of god(there is no reason you shouldn't be able to get your data back but you can't) should be canned and even under the act of god circumstances they should be apologetic.

  • by Proudrooster (580120) on Saturday December 06, 2003 @03:48PM (#7649234) Homepage
    Developers whine about not being able to willy nilly install anything tools they desire, code in the "cool" language of the week, or drag in any middle ware which is fun for them to playwith i.e. (Tomcat, Jaguar).

    The developers then work on their little projects, get them finished, and DUMP IT ON THE ADMINS and RUN AWAY (off to the next exciting project). Yes, the developers are typically able to coble together their cool Java Beans J2EE to .NET using CORBA, XML and exotic middleware, however they don't understand it, nor do they have any desire to feed and care for it. This results in yet another orphaned system that will probably need to be rewritten in just a few years since there will be no one around to understand it. However, nowadays it looks like the next re-write will take place in India.

    Unfortunatly, for the sake of the users and the corporation, the Admin ocassionly has to say, "No". Believe me, I'd like to let everyone install EVERYTHING and play all day and all night. Innovation, innovation, innovation to the extreme. And that security stuff, who needs it. Just turn off all that annoying ActiveX security for the ease of development. We wouldn't want to slow anybody down. Also, disable all the Java security and let applets connect to and from anywhere. Ditch it all, after all the world is a safe place. There aren't any bad people out there creating hostile ActiveX and Java applications, plus the firewall and virus checker will save us, right?

    Systems must function for the sake of the customer and the customer's business. For this to happens, there must exist a well understood development framework and compotent people to manage and maitain the framework. Without this, you are in the wild-wild west of systems and are heading for the land of perpetual system rewrites

    I am an ex-developer admin so I work with my developers to help them logically design their applications and database objects. I even tune their SQL, but I resist letting them go off in "cool" direction of the week, just so they can add a new line to their resume and dump yet another one-off application on me which is guaranteed to misbehave and be nearly impossible to upgrade.
  • bah! (Score:3, Insightful)

    by CAIMLAS (41445) on Saturday December 06, 2003 @03:56PM (#7649277) Homepage
    Everything this guy has to say is invalidated by the fact that he runs a company [javelinsoft.com] that offers full-fledged consulting services to - you guessed it - other companies!

    This is like a Ford exec writing about how Chevy sucks. Taken with a grain of salt, it is.
  • by adam872 (652411) on Saturday December 06, 2003 @03:59PM (#7649308)
    It sounds like this guy has had some bad experiences and therefore infers that it is the case for all of IT. I must say I'm a bit a affronted by his sweeping generalisation that IT admin is out of control.

    I currently look after a team about 100 developers, testers and technical writers. The situation I walked into was one where each software group had control over hardware budgets, admin, the whole shooting match. Needless to say it was an absolute mess. Permissions were all over the place, NFS and Oracle servers haphazardly brought up, no fault tolerance, poor performance and reliability, the list goes on. I took the approach that my job was to help these folks get software products out the door as efficiently as possible. With that in mind, I sought to make sense of the environment and let the developers write code and the testers test it. They still had some control over day to day stuff, but I manage their total infrastructure for them.

    This involved retiring unneeded systems, consolidating storage and servers, upgrading some machines, implementing some proper change management, auditing, performance monitoring, backups, standard system images etc etc. We are not there yet, but needless to say that there has been a significant improvement in the last six months. The coders seem to be happier and the infrastructure is more stable. That sounds like a win-win situation to me.

    I think the key for any admin is to make a partnership with your users, understand their needs and address their pain. I agree that some admins rule with an iron fist and have users cowering in their presence. This is counterproductive. But so is having no admin staff in a development centre. If the chance arose, I would actually like to work with the author of this article and perhaps help ease some of that pain :) I deal with folks like him in my work at the moment and I think it gets down to having them trust that you know what you're doing and getting out of their way.
  • by t0qer (230538) on Saturday December 06, 2003 @05:13PM (#7649771) Homepage Journal
    The author of the article is right on some points, especially the "admin does what they have to too keep their job" point.

    Politically speaking, being a sysadmin is like riding a k-mart skateboard in the middle double lines of the road with traffic buzzing back and forth both ways. You have to deal with everyone in the organization from shipping to the executive board and insulting the wrong person, even unintentionally could cost you your job. It's more than just a tech job, it's a lesson in both diplomacy and technology.

    Developers on the other hand just have to deal with their project managers. They don't have to come into work in the IT persons uniform (polo shirt, jeans, pager, cell phone) They don't have to be the "first ones" in the office at 7:00am because the CEO is a workaholic. On the same note they are usually the last ones to leave, because someone absolutely positively needed something done "ASAP" although the trouble ticket was submitted at the end of the day.

    I've worked with nice devs that were smart and understood what my job entailed. I've also worked with devs that were just so arrogant and annoying that it made me grow a grey hair or two. Either way they were always treated better than us corporate whipping boy gophers IT helpdesk people. I don't think the author has any place to bitch.
  • Before and After (Score:5, Insightful)

    by axafg00b (398439) on Saturday December 06, 2003 @05:27PM (#7649863)
    I've seen both the best and the worst of having admins involved, and in not having them involved. About three years ago, my firm rolled out a web-based customer service app. My comrades in UNIX, NT and my network team were only told that they needed to provide servers and connections, not that there was a major application rollout. The first day the app was in use, I had the operations VP screaming in my ear that his agents at our remote site were unable to work because the app was so slow. We found that, because of the undocumented and untested requirements of the new application, the WAN usage at our remote sites went from under 200k to maxing out two T1 circuits. It took two years to finally get that situation stabilized by increasing our bandwidth several times over (increasing our costs) and spending several man-years to correct the application.

    After a change at the CIO level, we now have multidisciplinary teams - programmers, admins, DBA's - working together to prevent such expensive oversights. The problem with the article is that it romanticizes the past. How many of us have had to live through DOS programs whose programmer assumed their program was the only one running? Today, more than in the past, we cannot afford to have walls built between the various groups in IT. The costs of failure are too great.
  • by Iamnoone (661656) on Saturday December 06, 2003 @08:19PM (#7650796)
    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
  • by Yonder Way (603108) on Saturday December 06, 2003 @10:58PM (#7651508)
    This article smacks of the typical chaos that corporate developers often bring to the table. The author bitches that IT won't give him admin rights to his PC, yet he neglects to mention when he did have them the sysadmin was having to call him frequently to explain the high amounts of bandwidth being devoured by his system after he installed Kazaa. Or how about the help desk ticket asking if there is some way to block all the pop up ads when it turns out Mr. Developer installed Gator or some other [spy|ad]ware.

    Yes, I'm a corporate bastard sysadmin. If I weren't a bastard the company would need four more of me to clean up the constant messes the developers create due to their complete lack of consideration for company resources. I'm not talking about the legitimate development work, either, but rather the pure crap that these guys do with their systems that end up introducing all sorts of malware into the internal LAN.

    Just stop your bitching, and remember you're not at home. This isn't your network. It isn't your computer. It's the company's. Try to respect that a bit more, m'kay?

Life. Don't talk to me about life. - Marvin the Paranoid Anroid

Working...