Slashdot Mirror
The Rise and Rise of IT Administrators
maffstephens writes "Have you noticed how difficult it's become to develop software? Not because software is more complex, but because there seems to be an army of administrators standing in your way - sys admins, network admins, database admins, runtime admins - the list is endless. They should be there to help us, to make our lives easier, but the reality is often very different. This thought-provoking article from Software Reality is all about the emerging culture of spiteful, dog-in-the-manger prevention amongst corporate IT administrators. Software development has become so inefficient as a result, it's no wonder so many companies are outsourcing."
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.
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.
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'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).
mogorific carpentry experiments
I work for a government agency in the U.S., and as you can imagine, it's saturated with sysadmins who watch over security, resource allocations, etc. Our solution was to build our own network infrastructure. We purchased two servers, cross-trained about six of us to work as admins on those servers, and completely bypassed the regular admins. The result is that we're one of the most productive organizations in our industry, because we were willing to put in a little extra effort to get around the problem.
It's good to use your head, but not as a battering ram.
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.
--- I do not moderate.
What I often see is the people who least understand the big picture when it comes to technology are the ones who feel held back.
...
..."
The people I see getting mad just don't understand the impact or implications their "simple requests" may have on others.
"Can't you just open up ports 135-139 in the firewall for everybody"?
"It works fine on my system, something must be wrong with the server"
and my all time favorite when people don't have a clue why their system isn't working
"It must be the network"
They really don't understand how their system works.
As an admin (LAN, WAN, firewall, server, email, etc... you get the idea) for a med size (3000 users) organization I often have to learn other peoples jobs just to figure out what the heck they are really trying to accomplish. It usually goes something like....
Customer: "We need
Me: "Why?"
Customer: Pick one:
1) Vendor says so
2) We tried everything else
3) Thats what someone else said
4) ?
Me: "What are you really trying to do?"
Customer: "What do you mean?"
Me: "Don't tell me what you think you need, tell me what you are trying to do?"
Once I understand what someone is trying to accomplish then I can often work somethign out for them.
Keep the Classic Slashdot.
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"
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
--Idiots, Every single one of YOU, A flaming mass of conglomerated morons, hey wait a second, isnt that how RAID works?
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 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.
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."
Don't waste time... procrastinate now!
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.
Friends don't help friends install M$ junk.
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.
Turn s60 photos into awesome videos with mScrapbook for all S60 3rd edition phones!
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.
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.
-- Given enough time and money, Microsoft will eventualy invent UNIX.
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).
Remain calm! All is well!
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.
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.
Any sufficiently well-organized community is indistinguishable from Government.
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.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
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.
Agrajag: "Oh no, not again!"
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.
:) I think they (IT management) think that things like wget is an example of what they would term "shareware".
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
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.
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.
"Thanks to the remote control I have the attention span of a gerbil."
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.