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.

  • 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.
  • 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.
  • 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).
  • 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.
  • 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. :)
  • 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.
  • 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.
  • by sleeeper (210375) * <slashdot AT bigelow-springs.net> on Saturday December 06, 2003 @01:53PM (#7648413) 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.

  • 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 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 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@getmpAUDEN.com minus poet> 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.

  • Have you noticed (Score:2, Interesting)

    by ignipotentis (461249) on Saturday December 06, 2003 @02:13PM (#7648578)
    How incompetent most "IT Administrators" are? For the most part, I cannot stand dealing with them. 50% have no clue how to secure anything, and the other 50% are so anal that they themselves can't do work unless they are in the server room itself. Most are all over "specialized" as well as under skilled. In any given organization, there is a Webmaster, Network Administrator, DBA... this list goes on and on; none of whom have any clue what the others are doing on their own network. My favorite quote from a network administrator when I asked him to set up an ftp server temporarily so I can transfer some files was "I'm not a ftp guy, we'll have to find someone who knows what that is."
  • not excused. (Score:3, Interesting)

    by twitter (104583) on Saturday December 06, 2003 @02:31PM (#7648686) Homepage Journal
    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 out from the gross inadequacies of their software. Virus checker, heavy comercial source code CVS, bogus restrictions on installing software, idiotic network administration which loses critical path source code and a whole pack of morons that can point to Gatner articles to justify the whole stupid structure. Of course, the "security" you claim is not provided as continued theft of source code from game developers and Microsoft itself demonstrates. At the same time, people using free software tools with competent administration are busy producing superior code for any platform. Big companies are in love with junk software and they are no longer competitive because of it.

    "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.

    Neither do I. I hope that my x-ray machine has got a free software embeded system in it, rather than some stupid WinCE, "fastest way to the COM" crap on it.

    What I'd like to see from you is a defense of any of the bogus practices the author mentioned. Give me something technical istead of insulting a strawman.

  • 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 nbvb (32836) on Saturday December 06, 2003 @02:42PM (#7648772) Journal
    Bullshit.

    That's *EXACTLY* how I *ARCHITECT* systems.

    Any of our systems with web serving needs, that's how we do it.

    If you don't understand it, that's not my problem.

    It depends on the requirements, yes, but for anything running Apache, Websphere, Tomcat, WebLogic, etc. this is how we've architected highly available solutions, that are (at least nominally) more secure.

    If you're going to question what I've said, go look it up yourself. It's a great architecture, and doesn't require any other inbound access other than port 80.

    (Port 80 --> CSS/SCA --> port 8000 to backend servers.)

    The clients never know they're talking to anything other than 80.
  • Re:In all areas (Score:2, Interesting)

    by saintlupus (227599) on Saturday December 06, 2003 @02:55PM (#7648872) Homepage
    I doubt it. Schools are known for overpaying their administrators while underpaying the teachers and giving their students a shoddy education.

    You're probably a troll. If not, you don't work for a school, I can tell you that.

    After I got laid off when Verizon moved their DSL support call center to Canada, I interviewed for a job with a public school district here in Buffalo. Being one of the chief technicians and administrators for a full district of eight or nine schools paid right around $30k per year with shitty benefits.

    Administrators, like school superintendents and such, make decent money. Support staff are the only people in education who get fucked over worse than faculty.

    --saint
  • by furry_wookie (8361) on Saturday December 06, 2003 @03:04PM (#7648931)
    Actually in the UNIX world its true..

    Systems Admins in UNIX are really "Systems Programmers"... because they are constantly developing their own tools, coding their own solutions to administration problems etc..

    The rule is: If you have to do the admin task more than once, then you should automate it... and that automation happens via coding up a utility via Perl, or Pyton, Java or C.

    Windows admins are about 1000x more clueless about software development than UNIX admins, because it's just not something they are exposed to.

    Many UNIX admins tend to have writing code about 20-40% of their job.

  • by Tim C (15259) on Saturday December 06, 2003 @03:18PM (#7649024)
    who don't know, and don't care, how the domain is setup, or how our print server is administered

    I'm a Java programmer, doing back-end code for websites. Why should I care about how you've set up your domain, or how you admin the printers? My code isn't going anywhere near them.

    Now, assuming that by "cluster" you mean "group of related machines that run the application, with load balancing, hot fail-over, etc", then yeah, I care, and I know how ours work too. But the printers? Give me a break. As long as they work when I need them, that's all I need to know - and keeping them that way is someone else's job. I'm not belittling it in the slightest - no printer, no signed contracts, no work. It's just none of my concern.
  • by 0WaitState (231806) on Saturday December 06, 2003 @03:19PM (#7649032)
    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 your self-righteous tone and implication that developers are incapable of architecting a functional, deployable system appear very self-serving.

    Knocking down straw men and delaying releases to make them more perfect doesn't make money (usually).
  • by love2hateMS (588764) on Saturday December 06, 2003 @03:22PM (#7649048)
    What a ridiculous statement. Every administrator in my company is a current or former programmer. We also KNOW how systems interact. Developers are usually fresh-out-of-school know-it-alls who do NOT know the big picture, and have never worked a day in a real business with millions of dollars on the line.

    I have had developers insist that the the database user for their application needs super-user privileges. I have had developers make code changes on a production box without testing, and then destroy a day's worth of data. I have had developers mix up their version control and give us old releases to deploy, which is a really BAD thing in a Ecommerce application. I've said it before and I'll say it again, programming is not difficult. Any moron can do programming. It is not calculus. It is not brain surgery. Most programming in the business world is very simple and repetitive.

    Good administrators have been there before. The fact that they may have programmed in C or C++ and not in Java does not mean they don't know what they are talking about. Programmers are the fast food workers of the tech industry (sorry, but it's true). Good programmers are very rare, and I love when I get to work with them, but I don't trust most of them as far as I can throw them. They only know the latest trendy programming language, they don't know the legacy systems they are dealing with, they don't even understand the database schema they are programming against.

  • by DJ FirBee (611681) on Saturday December 06, 2003 @03:43PM (#7649210) Journal
    Word. Developers want root on every box in the system to write beta code. Then they write applications that use the network in a brain damaged way like needing 400 ports in the tcp 1000+ range to be open at all times on your firewall. Then they implement their crap code on a cutover and you (the sysadmin) gets told "it's the network" for 3 weeks while 200 sniffer files shows it's not. The IT director is brainless and worries about his job rather than having a spine.

    They do some "patching" and then the developers go on to their next gig and you make the crap application that cost 2 million somehow run on you r shit budget.

    Been there, done that. In fact about every mainframe to mid range conversion for a large database has been there and done that. You know the biggest sysnazis I have ever seen are IBM guys with mainframes and their damn applications have lot less problems that Spanky Coder down the hall.

    Coders have a luxury of not working with and having to placate every one/group in the coporation and they have the gall to act as if they are on the hot seat.

    Look aat a programmers desk and then try to find the sys admins desk and then tell me who is busier.

    Christ.
  • by rbrander (73222) on Saturday December 06, 2003 @03:44PM (#7649216) Homepage
    The points I'll try to make have all been made by others, talking about "teamwork" and not "throwing it over the wall", but Professor Franklin's classic, "The Real World of Technology" [academon.com] clarifies the debate a great deal. She describes the difference between "Prescriptive Technologies" in which specialization is by task and "Holistic Technologies", in which specialization is by product.

    Example: In my workplace, several years ago, some of the drafting staff became, over several years, sysadmins. Their job was to make maps. And they made maps with paper and pen. Then with CAD terminals running off a VAX. Then with CAD terminals running off a Intergraph UNIX server. Then with CAD UNIX workstations. Then with Windows NT workstations, but now running far more UNIX boxes than ever: file servers, plot servers, database servers (the maps were now stored in Oracle in a GIS). So they had to become database administrators, too. But they did all this in service of making maps. Specialization by product - and learn any technology you need to, to do it.

    Developers used to be holistic, which is almost synonymous with "craftsman", and in turn with "slow production". They learned Assembler or FORTRAN or C or whatever, as long as it got their app out. They became a (minor) expert in whatever OS these tools were provided on. Now, prescriptive technology has become dominant in IT, with specialization by task: database admins, server admins, web server admins, and various layers and kinds of developers. Prescriptive technologies' endpoint is the Henry Ford assembly line: able to produce products far faster, and with tighter quality controls than all but the finest craftsmen, but less flexibly. (Which is usually bad in early stages of invention and development!)

    Teamwork means a coordination problem and only selfless teamwork - from everybody, admins and SAs and programmers all, can minimize the coordination inefficiencies. (see: Fred Brooks "The Mythical Man-Month", written when mainframe programming had become highly prescriptive - PCs and client/server programming broke up that model for a while, but now it's taken over the new technology as well!)

    I, personally, doubt that as much prescriptive technology as most organizations develop is really needed in development - one poster wrote of being "more like engineering". Well, I'm an engineer as well as an IT guy, and I would remind him of various "skunk works" approaches to physical engineering: shops where the engineers are king, managers are kept in place, creativity runs free, iterative developement is rapid. (Results of that work are developed by NON-skunk-works, more prescriptive, engineering departments into final products.)

    Similarly, I'd advocate most development go in two stages. Brooks again: "Plan to write it twice - you will anyway". The first draft of an app should come out of a "skunk works" where developers control their own servers, network, and software toolset. That prototype can go through the "administrator mill" of more tested, more documented, more approved-products-only process.

    And the sniping about "you aren't the one blamed when it dies at 3AM" can be approached by bringing a more "holistic" attitude to the development team. Make the DEVELOPER responsible for the app, not the administrator. Page HIM at 3AM. You'll find he is suddenly much more eager to work with the administrators to be sure the app works as well on the Official Production Server as it did in the skunk works.

  • by susano_otter (123650) on Saturday December 06, 2003 @04:23PM (#7649483) Homepage
    The scenario you describe doesn't scale for shit, you know. I'm on a team of about 300 sysadmins, netadmins, security admins, and DBAs. We support dev, production-test, and production environments for some 800 different projects ranging from "astoundingly trivial" to "major investment". There's no way you could find 300+ people who were all equally and highly competent system, network and security admins, and highly competent DBAs, and skilled programmers. Even if you could, you'd actually need 600 such people, since the first 300 or so wouldn't have enough time or energy to do all the planning and administration and do all the code design and production.

    There's simply not that many rennaissance hackers to staff even our company at our current size--and heaven forbid we grow at all! Let alone enough virtuoso geniuses to staff entire sectors of industry in the manner you describe.

  • by charnov (183495) on Saturday December 06, 2003 @06:05PM (#7650082) Homepage Journal
    Actually in group dynamics, three is the worst number as in most situations the two stronger will always gang up on the third. Larger groups of 5 to 7 work well with a creative goal. This is why special ops teams are the size they are.
  • Hmm.. Nice rant. (Score:2, Interesting)

    by MROD (101561) on Saturday December 06, 2003 @07:36PM (#7650567) Homepage
    The article's author lost all credibility for me when he discussed how he lost 2 weeks of important development code when the wrong *ROAMING PROFILE* was deleted and wasn't backed up.

    This person was relying upon Windows' flaky desktop look and feel saving software to copy his project onto the server. If that's not stupidity, I'm not sure what is. Not only would it be a highly risky strategy but it would mean that everytime he logged out or logged in all that data would have to be copied to/from the server. What's wrong with holding all the data on a network disk?

    I'm sorry, although some of the poor management practices and borderline admins have been highlighted in this article it also shows why the author shouldn't be the one slinging mud. He's as much to blame for the situation as those he is ranting about.

    From the remarks at the beginning of the peice, it is obvious that this developer grew up hacking code on non-networked PC's fully under his control and he enjoyed its freedom. However, when you're using a complex, interdependent networked system, one rogue program can cause havoc, be it imported or internally generated. This is why there are restrictions (which can be made too restrictive by management).

    The author also shows a certain disreguard for the problems of licensing hell in which we live today. Installing one extra copy of a program you happen to use in the lab and have the CD for can land your company in a major quagmire if an auditor finds it.
  • 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 Anonymous Coward on Saturday December 06, 2003 @08:58PM (#7650957)
    1. Most developers these days write in high level language. They have little if any understanding of the architecture of the system. Many don't care about anything on the system and act like their application is the only one on the system and could care less if it causes other problems. 2. The angry bitchy BOFH being griped about is the sorry bastard that must then support this environment. His ass is on the line not the developers. If the machine crashes or gets hacked it certainly isn't the developer getting up at 3AM to fix the system. It isn't the developer whose salary and or bonuses are based on uptime. The developer writes the application and makes sure it meets some arbitrary spec. and releases it by handing it to some sysadmin to install and maintain. 3. In many cases the Developer(s) do not include the sysadmins for the target architecture during the design phase. This must be done regardless of the architecture. Every platform has it's own idiosyncracies that must be planned for. If the sysadmin is any good (s)he is going to ask probing questions such as : A. How is this design going to impact the security on this machine and can we modify the design to be more secure. B. How is this design going to impact the applications already running on the system. C. What sort of patching scheme will be implemented to fix any problems that will crop up and who will be the support contact. D. What other support applications/libraries will be needed on the destination machine and who will be supporting thoses. Are those applications available for the destination platform, and what problems do those applications have on said platform. 4. Many but not all developer(s) hiding out in the corporate environment are not skilled developers. If they haven't spent a large amount of time chasing the latest greatest fad. ( C/C++/Perl/Java/C#/Php and the list goes on. This doesn't really give them the time to learn any one language very well. ) then they just junior programmers. 5. The above applies to sysadmins as well. Many of them just aren't knowlegable enough on the platforms they are responsible. You would not believe the number of admins who are moved from the "Windows" team to the "Unix" team with the passing comment from management "Your an admin, so we are going to make you responsible for our new 6800 cluster." Now granted the above statements do not apply to all developers or sysadmins but it tends to be a general rule. Large corporate IT environments are prime places to find the clueless developer/ sysadmin hiding out. As a senior level sysadmin and a junior programmer I have seen this quite a bit over the last 10 years. My whole diatribe comes down to, devlopers do not and should not have root access to arbitrarily install code on production machines. developers should have sudo access in a test environment to install and test their applications. developers and sysadmins should communicate more effectively and more often. sysadmins and developers should receive more training and/or be hired with the necc skills to write and maintain good and secure code if they are developers or for sysadmins have all of the necc skills to support their designated platform. Both should have exellent communication skills and be prepared to work in a team, not as the single most important entity in the company. The person who tells you they are so important that the company would belly up without them isn't ready to work in a team environment.
  • by Stone316 (629009) on Saturday December 06, 2003 @09:11PM (#7651018) Journal
    Back when I was in university people joined Computer Science because they were genuinely interested in it. Nowadays alot of people joined because they thought it was a guaranteed job. The sad part is they did history degrees first and then took a 6 months IT diploma program at some rinky dink school.

    Maybe its just me, but you can definitely tell who when to university and took a CS degree vs McIT schools. So now we have a market flooded with people who don't really have a clue and the sad part is management either doesn't care less or doesn't have a clue about who they are hiring. How many really competent people do you know in IT? For most people in IT, things just haven't gell'ed yet. They know bits and pieces but they can't see the big picture.

    I joined a company a year ago and inherited a badly designed application... Its freakin pathetic and i've actually had people laugh at the design. Who designed it? Some guy who didn't have a clue, spent 2 years doing it (its not a big app) and management thinks he's better than sliced bread.

    I'll admit it, i'm a DBA but I don't act like whats described in the document. Developers have what we like to call a *cough* development environment. Maybe he's heard of it? Its where developers have free reign.

    Now production environments are entirely different.. We have to have tight control.. why? Ask a DBA how many times he's been called to recover a table before a developer thought he was in dev but was in prod. Ask a DBA how often he gets put on the hot seat because an application performs poorly?

    Its unfortunate but admin people are the ones that get blamed not the developers. Why? Because most times its prohibitly expensive to redesign the application and people will fight to the death before they admit a mistake. So the DBA's, network, server have to fix it.

    As a DBA i'll promise not the be a pain in the ass if you include me when designing your app. I'm pretty sure all the other admins feel the same way. Don't come crying to me after you've put some assinine application into production.

  • Re:In all areas (Score:1, Interesting)

    by Anonymous Coward on Saturday December 06, 2003 @10:24PM (#7651364)

    Meanwhile, in other news, the Pope is Catholic.

    I hate to tell you this, but public school jobs are the very bottom of the barrel when it comes to system admin jobs. Let's look at some of the things that attract good system admins and evaluate whether public schools have them:

    1. Good pay? Nope, schools are known for paying their employees far below what they're worth.
    2. Good working environment? No offense, but you're hanging around with a bunch of high school students and teachers. All of whom are fine in and of themselves, but they are not necessarily interesting people to hang out with if you're a technical person. And is the building going to be relatively nice with a good office, something with a window? Of course not.
    3. Good management? School administrators and city governments are not known for efficiency or having a clue. In fact, they're kind of known for bureaucracy and stupid rules. And one of the things you look for as a system admin from your management is support from them on various issues, and that support usually requires them having a basic understanding of technology. Do you think most public school administrators know much about technology?
    4. A decent equipment budget? Haahaahaaaaaahaahahahahahaa!!!!
    5. Being part of a larger organization that's doing something cool and innovative? If you work for Google, you get the satisfaction that you're doing something cool, or at least that you're part of something cool. If you work for NASA (like I did), same thing (at least in theory). But what about computers in school? It's not even clear that they help education rather than hurting it. It's not clear that they are worth the money, especially when school budgets are in an absolute crisis right now. Schools seem to have rushed headlong into computers purely on the assumption that because they are technology, they will help education. In fact, many tech savvy people see the lunacy in this and are opposed to this. So it's sort of the antithesis of what many smart tech people would want to be part of.

    Chances are, the IT people at a school are the ones who couldn't get a job anywhere else and/or the ones who are in IT purely because it's a viable career option (and not because they love it).

  • by BenRussoUSA (454940) <`moc.liamg' `ta' `ossur.neb'> on Saturday December 06, 2003 @11:33PM (#7651614)
    This article sucked. There have always been wars between "OPS" and "ENGINEERING". Both sides have valid points and both sides have some areas where they are just too stubborn to listen. What this author really missed is that MANAGEMENT IS RESPONSIBLE FOR BALANCING THIS OUT. Both OPS and Engineering are necessary. Sometimes outsourcing makes perfect sense, sometimes it is really just managers being unwilling to do their job, and more willing to use the companies money to get someone else to do it for them.

    I've worked in shops where the "GURU DEVELOPERS" were actually idiots who wrote the crappiest applications in the world, and it was the OPS and Admin groups who kept everything running. I've worked in other shops where the OPERATIONS POLICE were procedure idiots, they had change control meetings to make changes to the change control policies, and it was the devel/eng'g group that kept picking up the pieces and keepingn things running behind the scene.

    Team building excercises have helped these situations in some companies I've worked at. Really, I know it is a buzzword, but I'm not talking about anything new-age, just getting everyone to go bowling once a month, or to play pool together. The company should spend the money to send people out of the office on PAID BUSINESS HOUR activities that are not work related. Let people get social and they will communicate better. When people realize that the folks on the other side of the fence are usually just as devoted to getting real work goals achieved, but that they are just seeing it all from a different perspective. It is really dificult because of ego's and stress and pride, and a lot of times people on the opposite sides of these fences have real disagreements, sometimes it takes a knowledgeable manager or director to listen to both sides, ask questions and make a decision.

    The author really clued me in with his consistently disparaging remarks about management. If you really have no trust/respect in the leaders at your organization, you need to find a new job.

Whoever dies with the most toys wins.

Working...