The Rise and Rise of IT Administrators 686
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."
We Need Less Planning and More Coding (Score:4, Interesting)
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)
Nothing against prgrammers (Score:3, Interesting)
Outsiders can see the flaws better, so outsource (Score:3, Interesting)
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)
Re:In all areas (Score:5, Interesting)
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:Have you ever stopped to think ... (Score:5, Interesting)
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.
Re:We Need Less Planning and More Coding (Score:5, Interesting)
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.
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.
Re:We Need Less Planning and More Coding (Score:3, Interesting)
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.
Not admins, not developers (Score:5, Interesting)
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.
Re:We Need Less Planning and More Coding (Score:5, Interesting)
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.
Complaining about Clearcase? (Score:3, Interesting)
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"
Serious attitude problem (Score:5, Interesting)
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)
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)
not excused. (Score:3, Interesting)
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.
Couldn't be more accurate (Score:3, Interesting)
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.
Re:We need more planning and less coding. (Score:3, Interesting)
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)
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
Re:Because Administrators are Responsible (Score:3, Interesting)
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.
Re:Nothing against prgrammers (Score:2, Interesting)
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.
Re:Have you ever stopped to think ... (Score:3, Interesting)
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).
Re:We Need Less Planning and More Coding (Score:2, Interesting)
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.
Re:We Need Less Planning and More Coding (Score:1, Interesting)
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.
From Ursula Franklin's "Real World of Technology" (Score:2, Interesting)
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.
Re:We need more planning and less coding. (Score:3, Interesting)
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.
3 is the worst number (Score:3, Interesting)
Hmm.. Nice rant. (Score:2, Interesting)
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.
Author is right on the money (Score:5, Interesting)
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
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
The real problem comes down to : (Score:1, Interesting)
Too many people in IT for the money (Score:2, Interesting)
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)
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:
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).
Six of one half a dozen of the other. (Score:2, Interesting)
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.