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.
Companies are outsourcing development becasue it can be cheaper, faster and better. Not becasue sys admins are in the way of developers.
Dont you just want to scream LET ME DO MY GOD DAMN JOB!? on a seconday note i will attempt to fulfill the daily quote of $$ in the word Micro$oft. There
http://www.DaveNet.biz/
Developers, Developers, Developers, Developers...
(That's all I hear these days, thank you Steve Ballmer)
As a sysadmin, the Devs need to learn how to play nice and keep the system stable. As a developer, I want total access to everything.
Solution? Developer network off the main network. If they blow it up, it's their fault and they fix it. Sounds good in theory. I think programs like Ghost will play a big role in this type of setup.
This is awfully reminiscent of that MIT article on /. a few days ago. What's the difference between 'outsourcing' and 'offshoring'?
absolutely. i work in a f500 corporation and as the dev manager i spend half my time convincing the program manager to convince the IT guys to let our stuff trickle out. i can totally see the IT managers point, that his job is to keep everything up all the time and if everything is changing underneath him, he can't do that! i am at least happy we have our own sandbox (which we manage, the IT folks will only swap out hardware, apply security patches, or format, nothing else), and we hand over new software releases on a quarterly basis. I don't think there really is any other way to do it, can't have random groups deploying software to production servers, i don't think the CEO or CIO would want to hear the finger pointing blame game when something goes wrong. gotta be a better way tho...
int i;
for (i = 0; i < ADMIN_LIST_SIZE; ++i) {
delete admins[i];
}
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
We're a cancer?
I think it's more that the software development cycle is becoming move evolved, as happened to engineering a few decades ago. The days of slapping things together and getting it out the door are gone, and good thing, we all see what occurred at Microsoft when quality wasn't a top priority. Buggy software with huge security holes.
IF we want the public to trust software and computers more we have to develop a more "engineering" like mentality. Otherwise the public will think rebooting your computer three times a day is normal and acceptable.
I say this from the point of few as both a system administrator and developer. There were times in my old company I would highly object to certain courses of action because they might have compromised security. This forced the developers to go back and rethink things. However the developer side of me usually had a better suggestion anyhow.
Which brings us to the next point, part of the developer "get it out the door" mentality involves a lack of understanding by said developers of how systems work. They learn their C++ or Java in school, but they fail to learn how the underlaying OS and hardware work. IT training has become job training rather then creating computer scientists. Perhaps things would flow better if all invlved better understood the fundamentals of computers.
I for one am not said to see the development cycle slow down. Far too many times have I see bosses go, "Just get it done, we'll worry about cleaning it up later." Do you want the software controlling your car or the X-ray machine at the hospital being managed by such a manager? I certainly don't.
I'm a self-employed software engineer / web programmer, and no one hedges my way or makes poorly informed decisions here...
I highly recommend it.
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.
Its always cheaper to hire and overwork an Indian or Chinese than to hire a typical snobby White American Male who will want overtime pay and a fair wage. Think about it, if you wanted to save money would you really hire your own? Hell no.
People don't exist to serve systems, systems exist to serve people.
I'm not defending all the admins, because there ARE a lot of clueless ones out there, but have you ever stopped to think that we're here as subject matter experts?
I'm a UNIX system administrator. My responsibility is to ensure my systems perform well. This includes actual performance statistics (I/O, CPU, memory), security, reliability, scalability.
It also means I need to scale up the hardware as applications grow. I need to keep tabs on what my systems are doing, and why.
I'm the "guy who gets in your way" because my responsibility is to the system, not to you.
I don't work for you. I work for the systems. They are my "customers" if you will.
Sure, I slow you down when I tell you "No, your app can't run as root."
I slow you down when I make you diagram your database so we can lay out the I/O correctly.
I slow you down when I make you tell me what you're doing with shared memory so I can tune my kernel.
I slow you down when I ask for projections over the next year so I can plan the hardware and scale appropriately.
I slow you down when I shut off telnet, ftp, r services, and every other plaintext protocol. You b*tch and moan because your expect script from 1994 needs to be rewritten, but too bad.
I slow you down when I ask for a detailed list of which ports your application uses, who they communicate with, and what IP blocks I need to permit access from.
Yep, I'm in your way.
That's my job.
And if you don't like it, well, too bad. I *DON'T* ask you why you're using C instead of Java. That's not my business.
I'm a systems subject matter expert. I don't pretend to be a code expert.
Your a coding expert. Don't pretend to be a systems expert.
Let me do my job, and I'll let you do yours. We need to work *together* and understand the interactions between your code and my systems.
Systems are NOT simple. They're very complex; you need to understand all the interactions here, from the kernel through the disk management (whether it be VxVM, LVM, or whathaveyou), through the network drives, through the firmware, through the HBA drivers...
Let me do my job. Yep, it'll "slow you down" a bit, but in the end, we'll actually have a complete SYSTEM that functions. Code, OS, hardware.
So you can't roll things out in an hour anymore. At least it works now.
I disagree. We need to focus on the quality, not the quantity. We need better planning, not just less of it.
I've been involved with companies who spend forever planning and twice as long coding, and they still produce crap. Why? Because the design is always done by committee, so no really good ideas get out there, and the design always ends up as a preoptimized mess with a few "management-approved" ideas thrown in.
I seriously think a small tag-team (2 or 3 people) should be responsible for projects, and they should take in all of the input and recommendations, and produce a solid spec by themselves.. rather than the typical '10 departments sit around a table for 20 meetings and produce a piece of shit' method.
mogorific carpentry experiments
Instead of taking the jobs that pay the most, find someplace with sane administraton. The 'case' about administration was roaming profiles and backups.
/project and /scratch) on it. Lastly, providing access to backups online is easy except for authorization. It's hard in a large system to automate the authorization for restore requests. We definately don't want one user asking for a restore of some shared project space of another group that contains data that they shouldn't have, etc.
A) DONT USE ROAMING PROFILES, USE A SAMBA SHARE ATTACHED TO A DRIVE LETTER, BACKED UP ON A UNIX BOX.
B) BACK UP THE PROFILES ANYHOW, LIMIT PROFILE SIZES TO SOMETHING SANE LIKE 30-40MB.
C) RESOLVE RESTORE REQUESTS PROMPTLY, LIKE WITHIN 6 HOURS AT WORST.
Three simple rules there. Undelete software is moot, most filesystems don't have that sort of support anymore. Having consistency on what gets backed up is easy, we have clear rules (and filesystem directories, ie:
In short, good admins know what they are doing, bad admins make your days suck. I think places with good admins end up paying their developers less because they offer a workplace where their needs are attented to easily instead of asking them to do it themselves.
Note that this has nothing to do with outsourcing, either. Outsourcing is happening because dev jobs are half-price in India, duh!
-- dieman - Scott Dier
I my office, the IT personnel grant or deny software installation requests (among many other IT-related tasks, but software installation draws a nice example). People usually want software because it would make doing their job easier. Does this mean IT should allow any tool to be installed? If a software request is denied, the requestor will sometimes complain loudly along the lines of "Your job is to make sure I can do mine, not regulate it," to which IT will retort "but if we allow any software, it will result in incompatabilities between departments ultimately reducing productivity and increasing maitenance costs." Both are right; this sometimes results in a bitter relationship, but lets face it, they're keeping checks on each other. A successful development company needs to find a balance between the two.
Blame outsourcing on IT admins, not on Bush.
Owner of a Mensa membership card.
Because these "adminstrators" know little to nothing about development, I spend hours in meetings
Because these "coders" know little to nothing about security, I spend hours in meeting trying to drill into them why the firewall is in their best interest, and why they should be using different ports for each protocol.
If we all just sat down and coded first, our productivity would soar.
And you end up with Microsoft-like products.
For too long developers have been held up as the ultimate in computing knowledge, while administration has been seen as some monkeyboy sitting in a computer room swapping tapes out.
As a result, nearly every end user of a developed system is given attention before system administrators and operators. The secondary result is SA's and operators are left with big piles of innefficient crap to wade through, and much of the pressure of making said piece of crap work. How many folks here have had to work in huge, bloated teams of SA's all to support an ill-concieved and poorly developed (but gee whiz does it look greeeat!) product, getting paged and phoned all night to come in an slap more duct tape? How many people here have had to manage a bunch of boot-camp MCSE's trying to do 400 manual processes an hour because "that's the way it was developed"? How many people here have had to explain to a customer that some piece of code written by a fresh off the MIS degree train VB developer isn't RFC compliant and therefore 45 percent of the people in the world won't be able to interface with it? How many SAs here have had to tune the crap out of boxes and networks because a login page makes 75+ ODBC database calls? How many security consultants have had to go in and basically tell a company that they'll have to repartition and reinstall every server because someone found SQL injection in an app that required superuser privileges?
The list goes on and on. Administrators aren't there to make life easier for developers, they are there to make things work--and make them work better, more reliably, and more securely. I'd suggest that this whiny ivory tower developer wake up and realize that coporations have gotten smart to the crap he's been turning out and further realized that the people who run the stuff are just as important as the people who write it and use it.
In short, he needs to learn how to work on a team.
Developers are smart, but they aren't the top of the computing pyramid. There are many other groups of people that are just as smart in different areas.
Where I work (I won't name where) the situation is ridicules.
As a developer I am required to help install / support software on our clients network (hint: think large, think uk, think health related). Mostly unix (aix) boxes.
For me to be able to do this I have to have access (and typically root access) to a LARGE number of our clients systems. However, despite being trusted enough to have this access to our clients substantial network, I am NOT allowed admin privileges to my own work station! (win2k).
So, I *could* rm -rf * (as root) some critical client box, but I do *not* have access to adjust the system time on my development PC! Totally crazy.
The worst part is it requires me to contact our admins to get an basic admin performed on my PC (install new software for example).
based on the asinine responses I'm seeing. "Its my job to get in your way" is basically what most of these posts seem to be saying. Know what? If you were technically inclined, you'd be a software engineer, not a fucking administrator. So get the fuck out of our way and let the smart people get the job done.
What's causing ME problems is Microsoft Visual Studio. With each new version, the damned thing gets more and more difficult to use, and the documentation (if that's what you can call it) gets harder to obtain an answer from. (Yeah, yeah: use Linux. I'd love to, but my customers want it done in Visual Studio.)
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!
And we need to just get rid of the whole system of labor and give all of you lazy American workers temp jobs. You idiots are too busy playing politics when you could be working. Maybe if you worked harder and developed better code than people in India you'd keep your job.
I don't see Indians being hired for game development and perhaps this is because game developers actually write programs that everyday joes dont write. Maybe you should brush up on your calculus and get a job at NASA or learn a bit about AI and work on something more innovative.
Anyone can make a Winamp/Mozilla/(insert easy to write open source app)
But most people cannot write a 3d engine, a kernel of the quality of the Linux kernel, an xfree86.
If you want your jobs, learn to work harder and longer hours, or work smarter.
People don't exist to serve systems, systems exist to serve people.
There are a world of difference from what the normal marketing person, executive, etc needs from a computer and what a programmer needs. Most people don't need much in the way of room to play around, and they shouldn't have that room.
Programmers are different. I write code, I need to test it. Maybe it needs root to run. You, as the sysadmin controlling my stuff, need to let me do that. In reality, there almost needs to be a different network for programmers, where they have the room that they need to mess with their code and see how it works. Sysadmins need to understand this difference. Programmers don't need root access to the network's servers, but they might need root access to a testing server, and it's the sysadmin's job to make sure that he can have a testing server running on a network.
Nice mindset there; you're a real team player. The reason we are there(network/sysadmin here) is to HELP you.
However, we're also there to make sure you don't do stupid things. While you say "these IT people get in our way", I point to a laundry list of really, really, REALLY stupid things developers have done at every company I've ever worked for; they just don't THINK about anything besides code, and they get Great Ideas without thinking through the consequences, either technology or business-wise. Some of it is just sheer laziness, and I've been faced with developers who act liked goddamn 5 year old spoiled rotten BRATS- this was particularly bad a few years ago when anyone who knew what "printf()" meant, got a 75k+ job.
Prime examples of stupid things I've seen: logging into machines using the root account because you're too lazy to use su. Or not allowing you to ssh directly into a system from your home PC without a VPN. Or yelling at you when you use temp tablespace for permanent data. Or not letting you move production functionality to some desktop system underneath your desk. Or using the database admin account for your application, instead of a seperate account?Or not implementing your latest code changes until you're willing to put down on paper that you actually did your job properly and TESTED the damn changes(do you know how many times I've seen developers just push code out without testing? Guess who gets blamed first. Guess who gets PAGED first, at 3am when it crashes. Management doesn't distinguish between a misnamed variable and a "Internal Server Error 500"; they're both production problems, and you're not in charge of production).
We're part of the team, and we're here to stay. You can either work with us, and clearly communicate to OUR supervisors(not just us) what your needs are...or you can make us the enemy, always try to do things half-assed, and get nothing done. Your choice- but management usually sides with safety, and we're the ones saying "that's not safe", and even if management doesn't side with us- when things blow up, we simply point to the emails we sent saying "that wasn't safe", and let you sweat it out while we restore from backups and clean up your mess.
Sometimes it's simply not our choice; it's "do it this way, tell Development that". You have no idea how frustrating it can be sometimes for even us- I once worked at a place where root passwords were changed on us sysadmins, and we were told "use sudo". The incompetent assholes a few levels up didn't realize that gee, guess what, if the machine crashes and fsck fails, you need the root password.
Please help metamoderate.
I think this article does a good job presenting the "developer" or delivery-oriented perspective. I've had the unfortunate pleasure of being on both sides of the fence. What I want to say is that there should be a counter-point article written for the "administrator" point of view. I've come to these conclusions after spending a years at Fortune 150 company: * Most developers cannot be trusted to follow procedures and to write code or perform deployments that work on the first try. * Most roject managers don't give a shit about security and will circumvent any sort of enterprise or application security if it will save them time in their delivery schedule. The IT admin's role (which is the hat I'm currently wearing) is CONTAINTMENT. When you have a 800 person development organization delivering three PeopleSoft modules, two PeopleSoft upgrades, 26 web applications (J2EE on websphere and weblogic, .NET and ASP on Win2k), several 3rd party datawarehousing projcets, you need containment.
Containment is key to preserving your production environment. If you can't hold developers, business analysts and project managers accountable through the test, QA and UAT process you are F*CKED.
Sure, if your company has literally hundreds of millions of dollars to spend so that each of your applications can get their own 32 processor IBM p690, then by all means don't care about process. But until quantum computing comes along, IT admins are responsible for keeping prod pristine and functioning properly.
What if you don't? You're going to have thousands of screaming users that they can't get their reports because some dumbass developer didn't follow procedure and put in a cartesian join when a certain line of code was executed. Worse yet, you may have your CIO called into the CEO's office to explain why the Finance dept. received bad data that was then in turn reported to the SEC and that a correction would be necessary. That's not fun.
In order to run a successful enterprise in this day and age, you need a multi pronged approach:
* good IT admins
* developers who write solid code and can package their software appropriately
* project managers who know how to do workplans and deal with scope creep
* SME's performing extensive QA (that are NOT in the project teams)
* documented (published in an easily readable format) policies and procedures
* change control (controlled by a change control board)
* organizational change management (helping users and business owners deal with IT change)
* enterprise security team that knows best practices (Confidentiality*Integrity*Availability)
* DBA and UNIX teams you can trust
I know I've forgotten some stuff but in my experience, large companies never have a perfect IT organization.
Oh, and this isn't meant to be a slight against developers. I am also a developer, and I'm not perfect. It's not the developers who read /. that I'm pointing the finger at, I'm talking about the guy who has coded VB all his life and is now trying to get into Java who thinks it's just as simple as copying his file to the Weblogic server not knowing about PROCESS.
Now I'm angry....obviously the user who wrote that article is a pissed off developer who can't seem to it through their head that processes and procedures are there to protect the server environment, end users and to ensure the validity, and security of corporate data.
If you cant work harder than Indians and Chinese why do you deserve the jobs? I mean damn, maybe if you were as smart or as hard working as others you'd never have to worry about being fired. Bosses do not fire people who are productive, stop taking lunch breaks, start working 12-13 hour days, work 6-7 days a week, and stop taking damn coffee breaks. Work 12-13 hours straight with no breaks, code as much as possible within that time frame. The people who code fastest in the least amount of time should keep their jobs and the ones who only write a few hundred lines should be fired immediately.
People don't exist to serve systems, systems exist to serve people.
On the one hand, I can understand the frustration of developers who have been arbitrarily undercut by surly, inefficient sysadmins. I've been there. A lot. On the other hand, the author of the article mentions at least one case in which he probably deserved to lose: software licensing. I'm glad you can deal with an InstallShield, bud, but that doesn't equate to knowing the terms of a license or how it will affect the company. And the fact that you don't acknowledge this issue suggests that you shouldn't be allowed to make such judgment calls.
Yes, we developers are a sanguine lot, continually making risky improvements with blithe optimism that they will work and actually improve things. And on occasion we are disastrously wrong -- that's what test systems are for. However, that's no justification for making it impossible to do our jobs.
After all, it's not as if most sysadmins are competent to pass judgment on our proposed changes. How many times have you heard an admin claim that he went into his line of work because programming was too hard? The odds are that his problem was with thinking things through and designing them carefully. In fact, most sysadmins do not appear to appreciate the basic concepts of scalable design, code reuse, or even revision control. And this is who wants to vet my software changes? No wonder they take all year -- they're too stupid to understand them.
If you do employ an admin who can do all of these thigns correctly, hold onto him, whatever he costs. Treat him kindly. Make his life as easy as possible. He is a rare specimen.
Some keywords for the NSA in the Lord of the Rings universe: One Ring bind find Sauron quest Nazgul freedom
... "http://www.whosoffshoring.co.uk/" as "http://www.whosoffwhoring.co.uk/" ??
~REZ~ #43301. Who'd fake being me anyway?
Are there sysadmins who've never coded, not highly skilled at what they do who are a drag to work with? Of course. Sysadmins run the gamut, the best (and probably most productive) have enough coding experience to know and work with the dev side also. The very best can run circles around the average dev imx. Naturally the very best devs are int the same class.
There are just as many 'developers' who don't have the first idea how to perform adequate testing, let along consider the constraints of running in a production environment let alone writing portable, consistent or maintainable code.
The author of this article is quick to bitch about a sysadmin losing his working files. Sure it happens. What the hell is with a developer who doesn't bother to keep any working copies of 2 weeks work? (In my own time managing a corp. network I'm pleased to be able to say I had exactly one instance of unrecoverable data loss -- where two users hadn't realized that NFS did not provide pc clients with any form of locking)
As a distribution maintainer (lunar) I see several OSS packages a week breaking reasonble build schemes or changing thier tarballs, (breaking MD5/PGP checks) without updating version info. So I'm sorry but there are no shortage of sloppy developers out there.
In my own engineering practice I've found over the years that all work goes better if the people doing it know they'll be held accountable for it over the long haul. Too many devs are allowed to get away with a 'throw it over the wall' mentality, going on to the next project and never having to deal with some of their cruft. Of course the same logic applies to the sysadms, I've seen lots of the behaviors the article rants about it but I gotta say ranting and pointing fingers ain't the solution.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Here's a quick test to try out on your systems administrator. Choose a tecchie topic like how a SAN works. ask them to explain it in terms a non-technical person can understand.
If they can't explain it in really simple terms, it's because they don't really know how it works themselves. Prepare to be dissappointed.
Remember, there are still a lot of sysadmins around who were employed at the height of the tech boom when all they needed was an interest in computers and penchant for manga to get hired.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
Just sent the lovely link to my IT Administrators, I hope they like it...
1) The great prison of groupwork has always been a innovation killer.
2) Programming open source is more fun (even if the money is zero).
I came to both conclusions about 5 or 6 years ago when everyone (mnaybe) still was thinking that IT is not entirely about consulting.
Sorry, but in these "anti-programming" days IT *IS* entirely about consulting.
I think your typical corporate IT project is rather larger now that it was 10 years ago. Software or not, most large projects bring with them increacing amounts of overhead.
The trick, of course, it to be smart about it, and I have no doubt that many organizations have far more overhead than they need.
I've been one of those evil System and Network administrators for over a decade now. Most of that time has been spent supporting software development labs.
I don't know what planet you or the author of that article live on, but I've seen a steady increase in the quality of software development and maturity in the development models used in the last decade. This may have slowed our development a bit, but you can see the results in our defect find rates. We're delivering a much better product than we used to.
Rather than just hacking out some code, doing a perfunctory test, and throwing it over the wall to be released, our developers are actually managed these days and do this cool thing called "planning." Yes, they actually investigate, propose, design, implement, and test code on a schedule. We even have teams dedicated to testing the systems to make sure they work. Oh, the horror!
In a decent software lab, which I consider mine to be, most of our management is also made up of engineers who rose through the ranks. These people know their stuff and trust the engineers beneath them.
In my area at least, we've also seen a large increase in the complexity of systems as well. No longer are our engineers programming a lone application to slap on a PC or a server. Our projects are large and distributed across multiple networks and servers. We have to traverse firewalls and worry about security trust domains and lots of other things that nobody cared about a decade ago.
I think that this increase in complexity of projects is likely responsible for the entire list of negative consequences that the article attributes to 'role fragmentation'. The only one I'd leave out is "de-skilling of the workforce". That may have been true in 2000, but the layoffs of the last few years have forced everyone to do work that was once done by multiple people.
All of that requires more attention to detail, and requires more effort to get right. I don't see that as good or bad, it simply is. Get used to it and stop whining about having to actually plan something and coordinate with others.
- Necron69
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.
Likewise, they have no real bureaucracy in the corporate world, mostly due to distance and the lack of regular face-to-face communication and personal issues. They don't have a team telling them what not to do -- they just do it, and it often works. They don't spend all their time in useless meetings, either, and often code all day for what amounts to pocket change for a US programmer.
Unless not only the government but also the corporations shape up and get rid of red tape and regulations, those 14 million jobs scheduled to go overseas by 2010 will arrive there ahead of time. Don't ever expect a populist political uprising to stop outsourcing, as that isn't going to happen in corporate USA, but deregulation is possible.
I know I am going to get modded down terribly for this. I dont care. Because this is my sincere opinion. I want to ask these average americans who bitch about outsouring , what is wrong with outsouring ? its part of globalization which is something america initiated, perpetuated and benefited MOSTLY. Giant american multinational corporations went and screwed up virtually every local industries and firms in developing countries. As a result of this american economy benefited a lot(whether it was just for a few rich or not is open to debate). Heavily subsidized american agricultural products resulted in devastation of un-subsidized farmers in the developing countries. All these time, these guys who bitch about outsourcing were happy with these. But when the same trend of globalization continued and resulted in so called "outsourcing" , all hell broke loose !!!. So where were you all when a HELL LOOOOT of farmers and other industry workers in developing countries like india were loosing jobs becoz of globalization ? Or is it that "anything is OK as long as we are at the receiving end" ? Why there is a hypocrisy when its outsouring ?
http://www.nasirudheen.blogspot/
Bullshit, American's were always Lazy. When was slavery used to build up Germany? Or the Soviet Union? You didn't even build up your own country! Everyone else built it for you and you claimed credit. I admit Americans do come up with the best ideas, they just are too lazy to use them. You invented electronics and you let the Japanese companies like Sony out work you. You invent the car and you let every country including Germany make better cars than you? You invent the computer and then you let India and China out work you and make better products? Thats lazy.
People don't exist to serve systems, systems exist to serve people.
No truer words have been said.
They need to wake up and understand that us developers are the true brains behind the enterprise. We walk on water. We are GODS I tell you. I can't count the number of times I've had to yell at my sysadmins for making the coffee too strong, not popping grapes in my mouth fast enough, or moving the hand-fans too slowly. The fuckers. It's as if they don't understand that their purpose in life is to serve me. That the entire company exists not as a profit generating entity, but as my personal support system. Heaven forbid I do something smart like suggest or create a decent PROJECT LIFE CYCLE to avoid conflicts with other departments. I'd much rather whine on slashdot. Now I have to go. My 3 o'clock rubdown is coming up and I need at least another 2 hours of slashdot reading time before that. I mean christ, what do they pay me for.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
BTW, nice troll.
You are being MICROattacked, from various angles, in a SOFT manner.
Maybe it's just more fun to write your own fancy open source project the world has been waiting for instead of wasting time on a bloated, stupid, closed source project your incompetent, non-programming and hurtful restrictive projectadmin has pulled out of his ass because he was able to connect so many IT buzzwords to it.
This article has some of the symptoms right, but it's got the root cause wrong. All of those things mentioned are problems caused by poor quality administrators (or just as often, poor policies that the admins have no control over).
:-) ). The best sysadmins are those that understand development and the best developers are those that understand the production environments.
Just as low quality developers with no sensitivity for production issues cause problems for talented admins, low quality admins with no knowledge of development cause problems for the developers. Talented administrators help your development team build bad-ass production ready apps and don't get in your way.
Mostly though, it's IT management and corporate higher ups that have created this sprawling bureaucracy, for a variety of reasons. The admins would love to change it, but really have no say.
As with anything, hire talented people and things will run more smoothly (as long as you don't shackle them with process developed by and for the untalented people
And yeah, there are BOFHs. Even sysadmin run into them themselves if the organization is large enough.
Administrators support production systems. Developers don't.
I've been a developer and an administrator. Administrators are cautious because they actually have to support the users of production systems. Developers are all free-and-easy because in general they don't have to directly support shit. This leads to a world view where everyone is holding them back from delivering systems they refuse to support themselves. If developers were forced to support production systems, they would be as slow and cautious as administrators (if they could even survive the stress)
Admins: an army of uneducated overbearing people. And now they won't let us do our jobs. If ever there was a case for anarchism, the existence of admins is it.
I'm an Admin that is currently trying to wring as much performance as possible out of brand new hardware because someone chose to make FoxPro the DB of choice for a 400 user app. Yay. Instead of going with a real DB they think the hardware is not tuned correctly.
Why has the administration been allowed to bloom unnoticed in the software industry when it is having all these negative effects?
Because Administrators are the ones who have to deal with the most headaches. I quit administrating and switched to development because of the complete lack of control I felt. The bulk of my admin was on Windows NT servers. A bad patch or rogue program caused grief, which I was expected to fix. Because of largely closed-source development environments, that meant flailing around in the dark trying endless shotgun approaches: patch, reboot, test, change, reboot, test, reconfigure, test, blow out OS, reload, test...on and on and on. Meanwhile developers would say "just get my database up and running! I don't care about _your_ problems".
Unix is the best environment I know for Administrators. It slowly nudges them towards programming because of the close relationship of scripting and automation. Admins grow to become programmers. NT on the other hand, is a completely non-sensical environment because it's prodiminatly adminsitrated through application layers; no programming knowledge required.
The old addage of freedom and responsibility applies. The more responsibility you have, the more freedom you should have. The less responsibility you have, the less amount of freedom is tolerable. Since a lot of admins work with closed-source products, they do not have the freedom to fix or investigate problems the way their open-source counterparts have, and therefore are given the responsibility without freedom.
Largely, I agree with the article's points, but I think the blame goes beyond the administrator. I think it belongs squarely in the lap of the commercial software industry. Then answer: open-source.
Ruby on Rails Screencast
You cannot assume that better=more expensive. You also cannot assume American=Better. IF this were the case cars made in Japan for less than cars made in the USA should be lower quality. Sony would no longer have a viable business plan, and China would not be manufacturing all of your stuff and taking your jobs.
People don't exist to serve systems, systems exist to serve people.
This says it all. The problem the author describes arises primarily because overall IT management is more or less clue-free. I have felt, and have said to anyone that would listen, that one cannot manage a technical staff without understanding what they do. The lack of understanding leads to a fear of losing control, which leads to the creation of more layers of rules and administration. This, of course, does not address the fundamental problem at all, but (the clueless hope) creates the illusion of activity and progress.
Here is how to do it right:
For each significant business/organization unit, create a segment of the IT group, run by a senior technical manager, which is entirely responsible for that business unit's IT: development, admin, operations, the whole enchilada. The IT manager's overriding responsibility is the satisfaction of his/her customer, the head of the business unit. Thus, the IT manager has:
- The technical background to do the job (by construction)
- A clear mandate (from the business head)
- The authority to make decisions and resolve conflicts (e.g., between developers and admins)
I have worked in this kind of environment (in financial services) as that technical manager, and it works. I signed a Service Level Agreement with my customer, specifying uptime requirements, project standards and timetables, support staffing, user responsibilities, etc. I had two reporting relationships: a formal one to the overall head of IT, and a less formal but more important one to the head of the business unit. Were there bumps in the road and occasional disagreements? Of course. But having a framework which everyone understood and had bought into was of enormous value.With this kind of arrangement, there will still (usually) be a need for some centralized services (e.g., voice telecom), and this is a potential trouble spot. However, with the user management on board, the business area IT manager has much more clout in getting those centralized services set up in a reasonable way.
Rich
SCO delenda est
Yes, it's true. Network admins' knowledgebase and compassion have dropped in the last decade while networking has become more complex. This is because of paper admins. The people who go out and get a certification and call themselves admins. They give the rest of us bad names!
Larger copmanies are implementing more sufisticated infrastructures to assist with mission critical and non-critical systems. This has resulted in having to seperate specific roles within I.T. departments. As with any well run department, you need to divide and conquer. Assigning one person (or team) for administration, DB admin, developement, etc. is the most efficiant way to make sure all jobs are getting done by someone whom has been trained to do that specific job.
The problem is that over the last few years, there has been a flood of network admins. The result is companies hire the cheapest person they can. Thus, you get what you paid for.
I have been a network/DB admin for over ten years now. I have to say that one of my most important jobs is to work with the developers. We both have a common goal; to make sure the user can do their job as easily as possible.
Maybe I have a different point of view from other developers because I too develope (on a very small scale). My point is we all need play nice.
..is not about programming anymore. It's about consulting and swearing the blue from the sky.
After you've done that you return to reality look very close at the needs of your client and pray that Excel will be satisfactory.
All this complaining. There's more people because computing has become more complicated. Simple as that. Kind of like medicine, and how our knowledge has grown.
I work at a computer science college in the systems group. As sysadmins, we give faculty the choice of either maintaining their own systems (under the requirement that they will keep up to date with security patches and such) or using significantly more restrictive (no admin access) systems-managed machines. And you know what? Everyone except for one or two people choose the latter.
This pretty much proves to me that as much as programmers and end-users bitch and complain about how much sysadmins get in their way, they sure as hell don't want to do it themselves. Goog sysadmins understand that programmers and end-users have jobs to do, but the reverse also has to happen or else neither side is going to get anything done.
According to the Jack Welch (ex GE CEO) whose organization GE is the pioneer of outsourcing, the main reason for outsourcing is that business parts that used to be in the backrooms become other organizations front rooms.
It makes a lot more sense from a management of the business perspective. Motivation is also usually higher when people consider themselves a critical part of a business.
Efficiency doesn't have to do with the amount of people something has to go through. Efficiency has to do with the processes that you need to go through. There are excellent six sigma tools out there that can help you identify what really is important and how to decrease lead time and decrease cost in your processes.
For further reference I recommend listening to the Jack Welchs' "Straight from the gut" CDs or for those with time to read, reading the book with the same name. If you are interested in Six Sigma, there are plenty of books out there with that name. The books might look to have a lot of information but the reality is that you don't have to use all the tools to achieve excellent results with your process.
Too many V.I.P's.
Too many very important products.
Too many programmer who prefer to stay happy and write open source.
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"
At my company, we use a BI solution that is three-tiered. Our server group maintains the app server, but they know nothing about the administration of the actual product. We tried to get ownership of the app server because whenever we need to change files or do anything that requires access to the box, it takes forever to get done. We were shot down because this conflicted with our new "Security Czar's" vision.
This BI solution is supposedly very important to the company but they refuse to listen to us. The other day I had to walk the app server admin through a process and he was asking me questions that should be known. Of course since I wasn't able to hold his hands throughout the entire process, it didn't get completed correctly.
This is a routine occourence with these guys. On one occassion, they had to change one line in a file to correct an error from generating in the application. It took about a month to get done. We had to open a ticket. I had to send supporting information on why this needed to be done. I had to remind the admin to do it. Twice.
The users are giving up on the product, but no one in IT Mgmt will understand why. They'll just assume it was the product and go to a competitor. And it'll start all over again.
-- You see, there would be these conclusions that you could jump to
Meetings. They take minutes and waste hours.
'Proof that VB is superior to PERL
&Option_Explicit
For i = 0 to (Admin_List_Size - 1)
Admin_List_Size{i) = "Goatse.jpg"
Show Admin_List_Size(i)
next i
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.
This article is great, but it should be forwarded to every CTO in the country, and then bcc'd to their CEO with an attachment that reads, "your CTO knows this now, so if they don't act on it in 6 weeks, sack them."
That might get some things happening! I certainly hope everyone who needs to read this and understand it can do that -- that's my special holiday wish.
stuff |
I work for a LARGE financial institution. I am a developer. I was, as the saying goes, born to code. I love it. All our systems are so goverened by beaucrocy and red tape by so many departments (most of which with NO accountability to anyone it seems) that it's impossible to do anything. Recently we had to move an unused server from point A to point B. It also had to have OS & Oracle reinstalled. This didn't require any financial approval since we weren't buying a new server and the project was already well funded. The move took 6 MONTHS. Once the box was in place it took me 4 hours to set it up.
Right in the middle of the move we found out that the SA's were no longer allowed to "moves & install" hardware, there was now a dedicated team for that. (?!?!?) The install of the OS took over a month. (Done by yet another department, not SAs.) Somehow, the Oracle install WAS allowed to be done by the DBA so that only took two days. Sheesh!
I recently got a new boss and boss^2. The boss^2 wanted to know why a particular app had so many problems, and I told him. He then told me, in pretty much these words: "Fix it! Dont worry about billing your time, just fix it!".
I was dumbfounded. No project, no project plan, no project manager, no approval for funds, no capacity plan, no meeting with the architechts. The only preliminary doc I delivered was a short blurb on my proposed solution which received a "Sounds good."
I've made amazing progress in the last month, learned a LOT, become a better programmer, I'm happier at work and at home, and built a solution that could save my company MILLIONS OF DOLLARS.
But I know it wont last.
IF my solution ever gets used (which I doubt...) then I'll be back to the same old routine. Any future changes to it will require the same old certification, proposal, architechture, blah blah blah. But...I'm happy now.
$7.95/mo, 200 GB disk, 2TBxfer, MySQL, PHP, RoR.
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!
That there is a reason why alot of admins are paranoid about giving anyone , not just developers, control of their box. The case in the article was an extreme example, but I couldn't help but wonder "What did some developer do years ago that completlty hosed everything?"
The back up situation at the place in the article sounded outrageous. The author had every right to be angry about that.
As far as the firewalls go..if there is a security breach, the developers would not get sacked and new abused ports are discovered. Users find ways of clogging everythign up with Yahoo! IM going through port 80, outside KaZAa users from Brazil suddenly thing that you have LTR Return of The King hidden somewhere on your network or script kiddies from Korea sudenly decide to scan port 1021 all day long...In other words, there are lots of reasons to change the configuration of a firewall daily (unless disconnected from the outside completlty..but no users want that).
Like NetNinja said, cleaning up after them is a nightmare, plus the admins are liable for the mess , not the developers. Communication between groups is the key.
That was true for me when I first started doing systems work as a colateral duty to software development. Many of the better sysads I've met started out as programmers. It's easier to relate to software development challenges and relate the systems group perspective which some developers do not see. Organizations are frequently a mix of end users and the IT shop; sysads are the glue.
I think you have Frederick Taylor to thank for a lot of this. You know, the guy who said "Leave your brain outside and bring your body indoors"? At installations like MIT, the computing facilities were maintained by hackers -- programmers who knew the system inside and out and so could serve as competent administrators. They made sure the system was working as it should for the real users -- and in their spare time played games or wrote music programs.
A lot of Unix administrators were the same way, especially at educational institutions.
These days we erect an artificial boundary between the concepts of "administrator" and "developer". This has the unintended effect of pitting the two at odds with each other. The administrators, bereft of useful and interesting things to do with the time they're not spending keeping the system up and running (which, though nontrivial, should not take up that much time on any decently engineered system), decide that the thing to do is to make more rules for people, because that is their job description and that's what they know how to do best. Because administrators are now considered separate from programmers, they lose touch with the kind of work that programmers need to do, and in their process of generating more rules the way Doozers build bridges, interfere with the programmers' work instead of making it easier.
Politics works the same way. The entire point of representative delegation was to get people who had a vested interest in a community to come together and negotiate just laws for that community, so they could go back to farming, shoemaking, medicine or whatever it is that they do. These days we raise and groom people for politics, making it so that making rules is the only thing they really know how to do. Then we end up with things like the DMCA.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
They would never go for it though. After the network gets totaly hosed by someone e-mailing a 2GB attachment to another developer during a critical time, guess who would be called in to fix everything anyway?
(I am assuming they would not put limits on the size of e-mail attachments)
I was a developer for years before ending up doing System and Network admin work. Developers alway blame the hardware, the OS, and the network first. Then we have to waste our time proving the problem isn't ours, but development issues.
No we aren't perfect, but I'd say 98% of the time the problems came from the developmet side. Todays programmers just don't understand much about resource management or how to write/debug threaded code.
So far, all of the system administrators I've had to deal with accept the fact that they aren't programmers and just concentrate on making the servers run correctly.
The few times I've had a run in with a SysAdmin, I've known FAR more than they have about the systems they are administering. It's hard for someone to argue confidently with you when you are right and can prove it.
To the poster who complained about the sysadmins, how would you like it if someone came over and told you how to write that function or that you needed to use an unchecked string buffer in that method?
Most of the people that I see having problems with SysAdmins are the ones that don't know what the hell they are doing and say things like "We need to open up port 1434/UDP on the firewall so that I can administer the SQL Server from my desk and from home." or "Just create a user with administrator priviliages on the server, we'll run the database and web app processes with that user. That way we don't have to spend a lot of time troubleshooting any permission issues"
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
OK, first of all, I work both as a network engineer and a developer. There are great admins out there, just like there are great developers. Likewise, there are horrible admins and horrible developers. I don't think either group has a monopoly on excellence or ineptitude.
That being said, The two jobs are really intertwined: admins should be contributing to the design stages of software just as developers should be keeping in mind deployment, administration and security factors when they're writing code. Sadly, I've met people on both sides that basically say "not my job" and move on. Those are the ones that cause problems.
BTW, I don't have a lot of pity for the author. He tries to make a point by saying his roving profile got deleted and it caused him to lose 2 weeks of work. Let me just say in my experience I have never gone that long without a commit. The rule I've always gone with is that if the build isn't broken it gets committed. There's really not an excuse, even in early development phases, to not be comitting often. This just sounds lazy.
Derek
Don't Panic...
Unless you want your development workstation compromised by Blaster cause your admin just "happened" to portfw 135-139 to your workstation.
Back in the mid 90s, I worked for a failing software company. This company had the perfect chance to cash in on the Internet boom, but failed to do so. Why? Because the head sysadmin deemed it too risky to give engineers Web access from their office machines. Instead, there was a single, slow workstation in a locked room that everyone had to sign up to use. As a result, the engineers missed an oppurtunity to play on the Web and come up with ideas for new, potentially company-saving, ideas. Of course, it didn't help that the executives were clueless.
When I see companies where administrators get in the way, it usually is accompanied by a management composed of folks that don't know the first thing about the current literature of software process(i.e. the stuff that comes out of proces like SEI at CMU) and who think they are God's gift to business because they have an MBA.
Usually such companies have a very short horizon in their planning and think only about costs and have poor practices of risk assessment(i.e. think Enron). US corporate leadership frequently understands money very well-and understands nothing else that is basic to their business. The reason that the US can seemingly afford this type of corporate leadership is that compared to other highly developed countries, the US has an exceptionally rich resource base and a lot of credit.
I don't think this situation will last forever-but some of the means by which that situation might change aren't entirely pleasant. The US has had a fundamental shift away from Industrial leadership towards financial and legal leadership.
The old Austro-Hungarian empire had some similar problems for example-and look at what happened there.
with the exception that I run out of quota every time I have to release.
But, I have to say that in 10 years, I have never had too many problems and my sysadmins (from universities and companies, both big and small) have always been very helpful. You can find good ones and bad ones, like in every line of business, but they still try hard to help. I am the only user with a linux laptop in the entire organization but they don't complain, they help.
To the student who is complaining about his sysadmin: good sysadmins, at least in the US, cost way more than what high schools can afford. If you read shlashdot chances are that you are interested in what he does. Offer to help and learn something that you can put in your resume...
You spend a lot of time using the word "stupid" and refer to yelling at people. Hmm.
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!
When you outsource coding, this problem is highlighted more, meaning management can finally do something.
/usr/bin or /etc... I've even seen this in some commercial software: AutoCAD LT, ACT, etc.
The only problem is that outsourced programming often times SUCKS. It's usually commissioned by management with little or no input from the people who will end up supporting it.
I have the unfortunate job of managing a large number of Windows 2000 workstations, but have them locked down so that users can't install random crapware or muck with the system settings.
Over the years we've had a few custom programs developed on a contract basis by outside companies. Most of them are buggy, slow (Visual Basic crap), and make assumptions they shouldn't. It annoys me to no end when users complain that the software isn't working and it turns out to be that the software is badly designed and is trying to write to files inside of the program directory or modify the HKEY_LOCAL_MACHINE registry hive. I mean you don't see many *NIX programs that demand write access to
Fortunately, our in-house developers are pretty clueful and their stuff usually works without a hitch.
And, as this reply suggests, why don't you give them root access on a test machine?
John.
He has decided that his problems are due to administrators, who are all clueless, and that he would be so much better off if his world was run by developers, that are all knowing.
The reality is that the authors problems are due to inept individuals and the corporate bureaucracy that keeps these inept individuals in place. The problems are not simply admins vs. developers. This is no different than any other profession.
There are countless bad administrators out there. Many/most do not deserve the title of Administrator. But, at the same time, there are just as many developers out there that should not be allowed near a keyboard and yet they are forcing new "applications" down end user's throats on a daily basis, "applications" that reduce productivity due to bad design and processing inefficiency, buggy and untested code, and a total lack of understanding of the business process.
There are far too many inept individuals on both sides of the fence. It is not about admins vs. developers.
One more thing, the author seems to understand that J2EE is a bad idea so, why does he continue to develop with it?
What the article entirely misses is WHY there's role fragmentation. My girlfriend works in the IT department of a large law firm, and she's tasked with one thing: the implementation, testing, and rollout of a new document management system. And it's a full time job, for months now. Part of it is because they're adopting the latest and greatest version of the product, but part of it is also just simply because the software needs handholding to get it working correctly. There are bugs, nuances, and various sorts of tuning (the web component doesn't work correctly if you keep your browser W3 standards-compliant with regard to number of concurrent connections, for example.) It's not like the admins got together and said, "Let's make this software really manpower-intensive to install so that we'll all have jobs!" The developers have written this stuff that way, although obviously not with that end in mind.
In the end, if there need to be so many admins, it's because the software demands it, not the other way around. And I tend to think admins are pissy because developers are increasingly giving them crap to administer.
For your security, this post has been encrypted with ROT-13, twice.
It's been my experience over the last 10 years in IT that developers know how to code (hopefully) and not much else. Certainly not how to manage systems and networks in an enterprise. Sysadmins, etc. are the bulwark that prevents developers from creating total chaos. And this article proves once again what a thankless job it is, and how developers Just Don't Get It.
Sysadmins are the people that take that shittily coded app and actually make it work in some practical way. Code doesn't just work by itself in a vacuum, you do need to spend time planning and designing to make sure it comes out right at the end. The reason that there is so much planning now is because the other way just wasn't working.
If you are a developer and want to fuck around coding all day then go find a small startup that doesn't have time to spend on planning and designing. You don't belong in an enterprise.
I'm going to take a view against the article, and maybe an unpopular one. I'm a Unix sysadmin, have been for over 10 years, came in from developing, and I manage the other Unix admins and DBAs.
One primary function is to keep systems available and functioning for the users. You know, that ones that do the work that pays the salaries of both the admins and the developers.
Often we need to rein in developers who want to do something in a particular way. Maybe because it's easier for them, or because they don't have a broader picture and see how it will or will not play well with other things, or even just because sometimes ideas work great in small scall on dedicated development platforms but don't scale.
So there are definitely times we say "No". I personally perfer to be able to say "would this work instead", but sometimes I don't have a clear enough understanding of their problem, and we both need to get our heads together to figure out a real solution.
Does this slow down the development of any particular app becuase they can't just throw it on willy-nilly? Yeap. Does it end up with a better total environment? I also would like to think yes.
All sorts of other *admin positions - some are needed, and some are chaff. A good security admin I expect to get into my face more then the developers face, and probably be well justified in doing so - hey, we need to upgrade to the latest patch of BIND becuase of XYZ security hole. Other parts may involve the developers - say the developers want web access from the internet to a system in your internal network for a client. If the security admin wasn't there, it would be quicker for the developer, but more detremental as a whole for the company due to potential security issues.
I may get modded down for the opinion, but let developers focus on developping, sysadmins focus on their systems, security admin focus on security, and have them LISTEN to each other. It's not that developers aren't smart enough to do sysadmin and security work, it's that they shouldn't have to be bothered to do it, let them focus on what they do best. Just like I might bring in others to clean up documentation instead of expecting my developers to have masters in English, we have other, needed, positions to make things run smoothly.
The article describes something that might work at a small shop, but a mid size or big shop needs more structure. This doens't mean ties and timeclocks, it means that we do have ways of doing things that keep things organized, and maintanable in four years without chaining that same group of developers to the project forever. And a lot of that requires extra admin positions.
Cheers,
=Blue(23)
LITTLE GIRL: But which cookie will you eat FIRST? C. MONSTER: Me think you have misconception of cookie-eating process.
On the other hand, there are some damn lame admins out there, so maybe it makes sense.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
For every story I know about a dumb admin fucking things up the developers, there's a story about a dumb developer who thinks he can admin.
The FA is just a bunch of whining from this particular person's viewpoint. Big deal. Does this rate a slashdot story? No.
The reason we have division of labor in big environments these days should be obvious. When your company handles millions of dollars they don't want the sales guys doing the budgets, they have dedicated people for finance. Specialization. If you want to wear all hats then find a small company where you can do everything at once and work 90 hours/week.
I should point out that 10 years ago it was much more practical for people in even medium-sized companies to be part-time admins because the systems weren't so FRIGGIN COMPLEX! When you've got 3 times as many systems now, and heftier software, and more patches and security threats to keep up with.... What might have been a 40-hour programming week with an extra 5 hours of admin thrown in 10 years ago, would now be 40 hours plus 40 hours. Most places I have worked as admins have been only too happy to offload this annoying tedium of system management so they could get real development work done.
And now, back to the whining....
You can either work with us, and clearly communicate to OUR supervisors(not just us) what your needs are...or you can make us the enemy, always try to do things half-assed, and get nothing done.
As a developer and consultant, I've worked in a lot of environments for a lot of companies, all falling at different points on the admin nazi scale. I've worked in environments were I was expected to do microsoft development without having an admin account on my own machine. I have no problem when admins come to me and say, "You can use that machine you found in the closet for an extra test box, but we're not going to support it." It's when they try to protect me from myself to the point of ridiculousness that I take exception. In those cases, I simply document the obstruction and keep billing.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
I beg to differ. The Americans all want to be chiefs, and so they bring the Indians in to do all the work!
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
"Corporate IT administrator" does not mean "Systems/ Network Administrator"
It means the brass.. the suits. Those who make decisions and draw up documents, and hold policy meetings.
This isn't about sysadmin -vs- developer friction.. that has always existed.
The author of the article has a valid point, but delivers it with far too much spite. He also makes several statements that betray a distinct lack of grasping the big picture.
Administrators are NOT there to serve developers. Administrators are there to serve clients. And, of course, so are the developers.
The author seems to think that administrators like to obstruct development just for the sheer joy of being a jerk. Never once does the author mention the fact that administrators are the ones who get paged in the middle of the night when the new code brings the system crashing down.
Administrators are given very simple priorities: keep the damned system up. If the system goes down, the administrator takes the heat first...and the developer is just asked to fix the bug.
Be cause of this, it is an unavoidable necessity that administrators will insist upon rigorious testing and strict adherence to policy.
Now, I am not saying that therefore administrators are right, and coders are wrong. I do agree that there is a significant degree of ineffeciency created by this bifurcation. However, I don't think it is fair to blame the problem on any single group.
OK first off I do this for a living and am an ex full time programmer. I left programming to leave working at big bussiness's slow pace. Having said that.
Yes programmers should program more and go to meetings less; they have nothing to add to a meeting outside of thats hard thats imposible etc etc etc let, the one lead programmer or better yet the Systems Arch go to the meeting for the tech side. Yea it's they guys some programmers hate because they are technical and see through the BS while pushing intergration solutions and other non programmer friendly things. Realy the coding aspect is only a very small part of the overall system. Archs need to be versed in a lot of different fields to get there jobs done (I laught when I talk to Architects that only have been inside the programming field fer projects work well without some networking and server hardware) this is so they understand the admins issues with there blessed production gear through the marketing guys that want to be able to use every buzzword known to man to describe the end product. Remember while the sys admins know little about programming, well they are paid to keep the system up and working and protect it with there jobs programmers dont get called in at 4am generaly they do. Programmers like most tech people need an interface to keep there time free and also to represent them tot he other departments given that person and the ability to work with them you can get better products and happier programmers most of the time (granted there will be the enevitable programmer hatred of this person as they come back with the management overridden bad ideas and shrug there shoulders.)
No sir I dont like it.
You walk into a dimly lit room, the shadowy figure a a muscular black man standing there. You walk to him, dropping to your knees. You grab his penis and start to stroke it. You try to take it in your mouth, but it is too big. You then lick and kiss it until it feels like an iron rod.
You then turn around and bend over spreading your ass, inviting him to penetrate you. You wait eagerly for the pain that you know you will feel as he rubs his huge cock against your tight hole. When he finally enters you, it is all you can do to stop from screaming like a little girl. You can't tell how long he is pounding your ass, time goes by in a blur. Then the cum spurts from your tiny penis, and you pass out. When you wake up, still sitting in front of your mac, you realize it was all a dream.
Where I worked a few years ago, many of my coworkers, mostly other electrical engineers, had little or no regard for admin tasks (I am personally paranoid about losing my work and I appreciate the value of a well maintained and regularily backed up system)
For example, one engineer was a Microsoft guy and he used visual studio a lot (most of used linux, but just couldn't). But he didn't use any sort of version control like sourcesafe. All the time, he'd make a copy of some code, do some little changes, compile and use it (usually as part of testing or communicating with some hardware which was the real target of the development effort). This lead to many hundreds of copies of visual studio projects. He was in a practice of copying the entire directory when making some sort of change... and it ate up massive disk space. He couldn't be bothered to clean up the projects (and in the days of VS 5, the gui-based cleanup option didn't delete many megabytes of precompiled headers and other intermediate stuff, but he wouldn't even do use the partial gui-based cleanup).
The result was taking up far too much disk space on the server. This engineer/developer response to the sysadmins: "disk space is cheap, so deal!" Disk space is indeed cheap, but managed disk space that gets backed up nightly is not cheap. The tape streaming is only so fast, and the tapes only hold so much data, and a number of applications can't run while the backup is in process... so there's only so many hours it can run at night, the server only holds so many disks without an upgrade that requires downtime and risk, and a lot of other concerns that developers don't think about.
Apparantly there was a bitter dispute between this guy and the admins. I think they eventually just got him a big drive and he used that rather than putting all that stuff on a networked drive. He probably didn't care, and it probably made the bloated visual studio build run faster.
But he'll probably be sorry some day if that not-backed-up drive fails, or gets corrupted by a windows-based problem, or something else happens that causes data loss.
So as a hardware guy, I've seen first hand a very bad "don't give a damn" attitude regarding even the most basic infrastructure needs, such as properly nightly backups.
Certainly, there is a point that a lot of sysadmins (especially the bad ones) create hundles and roadblocks. But if these people simply vanished, developers with such a bad attitude towards essential tasks like backups would need to clean up their acts.... or else the first hard drive failure would easily erase all the efficiency gained from not having to deal with those pesky sysadmins!
PJRC: Electronic Projects, 8051 Microcontroller Tools
but it seems that the author missed several of the intervening years that have led to the current situation.
In the beginning, the developers also were required to administrate the machines they were developing on and for. Shortly after that, as there were more deployments, there were folks who's primary task was system administrator, and they would perform development tasks according to the needs of the organization and in order to make thier own jobs much easier, then came the network administrators, who would also develop software according to the needs of the org, and in order to make thier own jobs much easier. Then it all went to shit as the marketing department realized that there was money to be made, they began asking for needless software with dubious need and poorly thought out devlopment requirements that could be used marketing fodder. The administrators became notorious for (rightly) defending defending thier turf and saying "not on my network. not on my system."
So the role of developer was born, a person with skill in writiong code with the willingness to write program asked using whatever programing language specified without any objection whatsoever, regardless of the technical merit of the spec, the need for the program, or the overall effect on the system, as long as they were paid. All applications were written in whatever the language of the day happened to be, and fufilled the purpose of whatever the flavor of the month dioctated. What had been elegantly designed systems that specifically fufilled the needs of the user using existing tools (most often transparently) whenever possible, using custom (or community) designed software whenever necessary, and requiring the least amount of system rescources possible, now became incomprehensible morasses of rediculously complex dependancies, multiples of propietary protocols that replicated each others capabilities but were "incompatible" with systems that served the exact same purpose, huge collections of libraries all addressing the same needs and differing only in what would justify the high cost of the (propietary) product, and an absolute disregard for any sense of of efficient and elegant network, system, or application design.
The design process has been divorced from the persons who use the apps, maintain the systems, and have the best knowledge of the needs of the given organization. Software development is now managed by sales people, marketing divisions, and corporate executives, most of whom have little real knowledge of the IT feild other than what they read in Gartner's artcles, and will accept the advice of a "consultant" before even considering asking one of thier own employees. These are the people who believe that the best developers are teenagers, that ".net" is the "way of the future", and that when a sales person tells him that thier product achieves something never before accomplished, or that it provides capabilities available nowhere else, they believe this.
Now the developers are crying that they don't have domain administrator rights on the network, or that they cant write to directories that they have no reason to be writing to in the first place. They bitch when the network has been infected by yet another virus, but complain when the administrator strips all VB script attachments from thier emails. They bitch about how much work they have, about thier hours, and about thier pay, but drop to thier knees for any manager that brings them yet another impossible to implement product idea or project that serves very little purpose (other than as something that might sell). They bitch that the admins are fscking around all day without understanding that this means all is well on the network and the admins have done thier jobs well.
This is the problem in the development world, and it is being addressed by Open Source. True, there may be some job loss a
Read, L
However, there's a real need for administrators, and increasingly so, as the systems get bigger. I'm the lead DBA for a app development staff of 25. Do I get off on holding the keys to the databases? No, but we ran for a long time with developers as sa. The bottom line was that there were a lot more problems than there are now that I locked the dbs down. I also realize that that puts a greater burden on me to not be a bottleneck in the development process.
That said, the problem is not in the fact that you have administrators, it's that you sometimes forget what your role is. Developers forget this all the time, that they are supposed to be responsive to users. Administrators forget that they are supposed to be responsive to users. Customer service forgets that they are supposed to be responsive to customers. I have to occasionally step back and remind myself of the fact that I am there to support the developers. But to think that this is only something administrators are prone to is to try to single them out as being exceptionally sinister. It's just human nature, and we all have our way of sometimes screwing the people we are supposed to be helping. Contact your local congressman for more details.
Every day, I spend time configuring the system and developing policies that give the developers the greatest freedom possible while maintaining stability. And in general, the developers appreciate the effort. Why? Because each one knows that, while he is sometimes hindered by my policies, he benefits greatly by everyone else following them. And therein lies the whine of the selfish developer. He wants everyone else to follow the rules to make his life easier, but he doesn't want to follow them himself.
I realize that Mr. Sharp was writing with a touch of satire, but as one who manages both developers and admins, I must respectfully ask whose duties are most easily shipped offshore.
Look, I'm a managing engineer myself, and all this reverence for developers is romanticized at best. If you can find a good tech/engineer who can keep today's RAD-slop running in a heterogeneous server OS environment, you'd better treat him/her well. If the developer gets petulant, all you have to say is, "Son, I can outsource you in one hour." The people who have the real knowledge of IT infrastrucure are the front-line admins. Any developer with credentials (IIT?) can pick up where your coder left off, but what are you going to do when the team that did everything from setting up your routers to creating backup schemas to designing WAN failover and balancing tells you to kiss ass? I've watched "imported" admins take days just to get a reasonably accurate schematic together for networks of a few hundred people. Your engineers make it all work. Don't piss them off. Live with it.
It's only funny until someone gets hurt. Then, it's hilarious.
Can you spell MCSE? I knew you could...
I inherited support for a corporate document repository a couple of years ago. This system was written in-house, and completely built and managed by the developers.
Here's a quick idea:
Server was floor standing in a wiring closet at the location the developers worked in. Not, in a rack at the corporate data center (with redundant power, switches, etc).
The server had 10 (!) 100BT NICs. They were all teamed and run into a 10/100 hub on the floor that then had one uplink at 10BT.
Server had a very nice 6 channel RAID controller that was completely unused. Instead the hard drives were connected to the internal SCSI and software RAIDed.
Moral to this story: Yes, developers and admins should work together, but each should respect the other in their field of expertise. If the admin tells a developer something is a bad idea, they probably have a reason for saying that.
Kind thoughts do not change the world
According to Steve Ballmer anyway.
From excellent karma to terible karma with a single +5 funny post...
Maybe the problems with keeping development, deployment, and systems administration in sync would be helped by that level of glue.
The result would be that the fragmented systems administration level would be simplified since they wouldn't have to deal with configuration issues except where they impacted ... well ... systems administration.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Fair enough. I was pretty angst ridden this morning, and hearing some developer whining about people in my profession, who get paid far less than they do, have to put up with a lot of crap, and are usually the first to get laid off- just touched a nerve. Unfortunately, slashdot's comment model just doesn't reward those who take a long time to post their comments.
Still, looking back, I stand behind the basis of my comment- that many developers don't have a wide vision, are very demanding, and don't appreciate that, in the end, we're there to keep them from screwing up. We're all on the same team, but I have little patience for those who don't recognize why we IT people exist.
Please help metamoderate.
Developers tend to do what's expedient, not what is secure, managable, scalable or even reliable.
The worst architectures I've ever had to sort out were put together by ex-developers who seemingly had no concept of complexity management. My god, the NFS crossmounts, the inter-application dependencies, the amount of shit running as root for no particular reason. Spaghetti systems are unreliable, insecure, slow and fucking expensive yet they are a favoured architecture of many developers as administrators.
It takes 5 minutes to throw some half baked shit down and call it an application but does it integrate with the middleware, does it authenticate on the corporate directory, does it perform atomic updates, does it use privilege separation? Does it meet business needs?
Does it fuck...
Frankly the people who pull this crap deserve to lose their jobs to the Indians and the Chinese because they do a better job, they're software engineers while you're just a programmer.
Government of the people, by corporate executives, for corporate profits.
I'm a little touchy on this topic, because I used to be an admin in a cross-platform Unix shop. I was let go when the money got tight, under the exspectation that the developers would take over my position in their spare time.
Three months after I left, they had to hire two admins to replace me. (One for Sun, HP and Linux, and another who could handle AIX, AS/400 and the mainframe development system.)
Administrators do a lot more than sit on their ass cruising slashdot. Capacity planning, filling out purchase requests for everything from extra ethernet cords to $85,000 Sun Ultra Enterprise mainframes. When that stuff shows up at the front door, it's the admin who plugs in the patch cables, and OS's, configures and installs in the datacenter the Sun. This is all time developers could be coding.
What's worse, many of them just didn't have the skill set or the mindset needed to be an admin. Rotating the backup tapes of the NFS server is second nature to an admin, like getting that first cup of coffee in the morning. Yet it wasn't done after I left... not one of those 50 programmers thought to do it. So they lost a month's worth of work. (They also didn't offsite the backups.)
It took one guy a week to figure out how to change the network configuration on an AIX box... a week he could have used to work on revenue-building product. (He didn't even know about SMIT, but wrote a half-assed startup script using IBM's wonky AIX system commands.)
This was in a tiny developer... maybe 50-60 coders and QA'ers. The picture changes even more dramatically when you are trying to write software to fit into a huge IT infrastructure.
The reason why there are so many different kinds of administrators is because there's simply too much for one guy to do. Most developers don't have the mindset or the skillset to manage a 24/7 computing environment, and they sure as hell don't have the time.
There are =some= developers who can install DB2 on a Windows box and keep it concurrent and compatible with DB2 on the mainframe... or even realize there are serious differences between tthe versions of DB2... the author isn't one of them. Even if it's developed on the PC, it will probably be deployed on Big Iron if the project takes off. Understanding that requires experience and an understanding of how all these marvellous toys are going to be deployed in the enterprise.
Basically, the problem the author has with his development environment is that it's bog-standard corporate... Microsoft products on personal computers and workgroup servers, and big boxen in the back room running Java.
While it would be nice if the company would buy you a PC and a database server, gave you a network connection and said "Go to it!", that environment wouldn't produce software that works with everything else in the system, or worse, would introduce instability and dataloss.
Virii are a problem if you use a microsoft platform, whether you're a 1337 coder god or Larry in Accounting. If you need exceptions to standard corporate practice, that's something your manager should be dealing with the IT staff with. (And the IT staff, admins and their managers, all the way up to the CIO, should plan on and quickly implement exceptions to policy when needed. But that's another rant.)
SoupIsGood Food
I used to be a developer, now I am a DBA. I am one of these fierce pit-bulls that stands in the way of "progress" from the developers point of view. I am vicious, and will bite your hand off right up to the elbow if you get too close. Why am I like this? Because the production system that I am in charge of generates over 1.5 billion dollars in revenue. When fly-by-the-seat-of-your-pants developers slam something together, it is usually a big huge piece of crap that impacts the system in a very bad way. When this happens, the money loses cash. Period. There is a new breed of software developers, at least in the Micro$oft world, that cut their programming teeth on VB6. They do not understand formal testing processes, they do not understand quality assurance. One guy told me yesterday that if the GUI responds within 29 seconds, that is good enough because the user said that 30 seconds is too long. What rubbish. When I was a C programmer 7 years ago, our concern was quality, speed, accuracy etc. Now it seems they are only interestes in slamming crap together just so they can move on to another project. So don't you dare say that we admins are slowing things down. It is your own crappy software development skills that is to blams.
I think what's needed in this area is more devolution.
Speaking as a both a developer that hated my system administrators and a system administrator that hated (at least some of) the developers around me, I think there needs to be more voluntary separation.
There needs to be more emphasis on a personal desk top systems that developers can do what ever they want to, including rebuilding and fixing as necessary, and shared systems that they are not allowed to touch the internals of.
The only way to allow both developers and system administrators to see the world in their own way, is to keep them apart.
Personally, I'm ready to find another career.
Okay, so all the stupid admins are making life difficult for developers.
Here's an amazing twist: all the stupid DEVELOPERS are making life difficult for the administrators.
Jeebus people! To pigeon-hole all administrators as ignorant bufoons whose only job is to place roadblocks in front of these poor, superior developers is the height of I.T. dumbness.
Stop being brain-bigots. Ignorance is not welcome anywhere in the chain of development of implementation.
Stop whining ya bastards because as an administrator I'm tired of trying to implement unusuable, unintuitive, and downright crappy software from ignorant developers.
Not to mention that if you outsource, who is left to improve your software when the people you outsourced to starts their own company and screws you over? All of a sudden you are forced to buy that bug ridden piece of s**t yourself.
Best bet is either to develop in house, or wave some dollars in front of some GPL hippies who then gladly code what you need (in the case where it doesn't matter if someone else also has the software, i.e. you won't go out of business because of it).
At the first company I ever wrote code for, the programmers owned the system. The programmers installed upgrades, the programmers were on call for system problems. It encouraged perfect knowledge between developing and administering... if you don't want to be called in at 4am because of a hung batch job, you made sure to write it correctly the first time. The only 2 non-programmers in the shop were one LAN guy to keep email going, and one help desk guy to IPL every 2 weeks and recover lost passwords.
The last 3 programming shops I've been in, all F500 companies, the programmers weren't even allowed in the same room as the hardware. The sysadmins ruled the roost and had everything locked down from the development team.
This taught me two things...
1. Allowing the monkies who recover lost passwords to run things causes more problems than it will ever create.
2. Password monkies will make up lots of new rules and policies to make themselves look more important to IT than they are. (Job security)
Been there, seen it.
It's quite an unfair brush that we are painted with.
Some of us do put our user requests at the top of the pile - yards ahead of the bulk of procedure. We strive to have a can-do attitude to everything. This even includes taking requests seriously when we know they could prove negative to the environment.
While many of we sysadmins are not developers and in many cases, can never be developers, it is also true to say that many developers are not sysadmins and don't have the temperament for it.
In my experience, sysadmin is 20% technology and 80% personality.
I'm suprised you don't know this, as Henry Ford was such a big fan of yours. We didn't invent the car, just the methods to mass produce it, making it more affordable. Karl Benz, a German, designed and built the world's first practical automobile to be powered by an internal-combustion engine.
I am no developer. I am a SysAdmin with a basic knowledge of several languages, which allows me to do my SysAdmin job with a little respect for myself.
BUT I respect software developers more than anyone in the industry. At heart I want to be a genious programmer, but I don't have the mindset for it, or the patience.
I know admins that are killing our industry. They have no passion for technology. They got into administration for the money. They got their paper MCSE and would be out of a job if we took their rodent away. They don't RTFM.
These messed up administrators buy huge GUI based programs while I hit a few keys in my console and accomplish the same task.
Step 1, redefine history to suit your goals. ...
Step 2, divide the audience into good guys and bad guys based on the history in Step 1.
Step 3, exacerbate conflicts between the audience teams defined in Step 2.
Step 4, Post to Slashdot.
Step 6, Profit!
"Nothing was broken, and it's been fixed." -- Jon Carroll
As a Network Admin, I have noticed that most of the people in my company, especially the developers, could care less how difficult my job is. They don't realize that I have many responsibilities, which span every department in our organization. I cannot take special care to make one department happy. Developers are the worst. They act like the needs of others within the company are not as important as theirs. I am not employed to make the jobs of just one department easier. I am employed to make the jobs of everyone better. If this means that I have to do something that the babies in development don't like, so be it. I don't see anyone from any department striving to make my job easier...in fact it is quite the opposite. People using company equipment and bandwidth to listen to music, read "news" and send snide remarks about their Admins geek sites. GROW UP!
Firewalls. I don't know about how the network at this individual's company is organized, so I don't know how many, what type, or what use of firewalls would be appropriate. The author certainly doesn't either - after all, he's just finished saying how roles of development and administration have been segregated over the years. Although he castigates admins for knowing nothing about software (sometimes true, sometimes not), he commits the cardinal sin - and primadonna hallmark - of assuming that he, a developer, knows everything there is to know about network design. But the reality is that he doesn't have the first clue as to how firewalls should be used in his organization, he just likes to complain about how they are being used. The admins could certainly change the network, but he'd still complain. In my experience the only way developers are ever happy is with a single totally flat network with each machine on a public IP and with no firewalls or routers whatsoever. How long you reckon that network would remain usable? How long you reckon your precious source code would be free of corruption and damage? Yeah. But hey, those admins don't know what they're doing, I'm sure the author knows much better.
Antivirus. Look, Jack, if you would use secure software we wouldn't need antivirus. Since you won't, and since we all know you don't bother to apply patches, you have to use AV. If it slows down your machine, that's just too damn bad. God knows you demand such ridiculously overpowered machines anyway (what? the guy in the next cube has a 3.06GHz CPU? Why do I have to use this lousy 3.0??? Get me a new one NOW dammit, this is gating!) that it shouldn't be that noticeable. But if there's a virus outbreak that brings the company's network to a grinding halt, guess who gets called at 3:00am? Not the developers, I can assure you. These are the same people who do things like bring in their personal laptops and desktops and plug them into the corporate network. Sure it's not allowed, but hey we're only admins, and surely a developer knows best, right? Blow it out your ass. If I had my way any person possessing a Windows box without AV in my buildings would not only be instantly terminated with prejudice, he'd also be sued for gross negligence and failure to perform. With the damages we recover we can hire more admins to mop up the worm outbreaks your me-first attitude causes.
Backups. Well, no, we can't back up everything. You're definitely right that we should communicate exactly what is and is not backed up. Guess what - even when we do, you still bitch and moan every time you delete something on your workstation that you shouldn't have, and then you tell your boss to "make those IT assholes start backing up every file on my personal workstation" because of course, as a developer, the world revolves around you and your desire to work in the way that minimizes your own effort, and the IT folks will just have to adjust. If that means buying $500K worth of tapes and hiring 25 more people just to swap them every day, well then, that's just the cost of doing business. God forbid you should have to check your code into the repository that we religiously back up, or actually use some of the shared storage space we support. Then you wouldn't feel SPECIAL.
Process. Yes, goddammit, the process is king. I agree with you that stupid processes should be replaced, but developers always feel that any process is stupid. Face the facts: IT isn't able to hire any number of people they want any time just to satisfy your own personal desires. We are always far understaffed, unsually by a factor of 3 or more. Out-of-process activities are an enormous drain on our time, and they alm
One rat hole that IT departments go down is trying to get one configuration to serve everyone. It won't. Managers and admins need good e-mail and calendaring. Developers need something radically different... and much more flexible. A lot of arguments happen when IT tries to force the generic solution to non-generic problems.
:-)
Giving developers there own firewalled-off sub-nets makes sense some times. I used to run a software validation lab. I *knew* we would be installing dangerous shit, like buggy network drivers, beta OS's with experimental network file systems, etc. Anybody can see that there is no way my lab should be on the corporate network. The corporate IT department would have stonewalled all the way until a VP cracked their skulls. They were/are stuck in the "one-size-fits-all" mentality that can stop productive development work cold. Fortunately, our division had our own IT department dedicated to supporting developers. They helped me solve the problem. We built a dual-homed file server (with no back-up, just RAID). Basically, a firewall that routes zero, zip, nada. But we could push files back and forth to the "real world". The chaos of my lab was thus contained... my team was only allowed to shoot their own toes off
Its about identifying and solving the *real* problem. In this specific instance. Not force-fitting the generic solution onto a unique problem.
The fundamental mistake you're making is in not understanding that you do not directly make money for your company, you _cost_ them money. The developers directly make them money.
Is this fair and accurate? Nope, of course not. But it's a simple fact that this is how upper management views things, and you'd be wise to grasp this concept.
Disclosure: I'm a long-time developer. I have often worn both hats. I have also in the distant past been an administrator.
I read this guy's article, and I feel his pain. He is clearly suffering in a bad corporate environment.
What he has done is scapegoat administrators, when what is happening is not a problem with administration, but with senior management.
When there are too many administrators, when they are not doing their jobs well, when they are deploying bad tools, when they are poor communicators or worse, obnoxious... when, overall, policy is bad, and the work environment is imperilled, look up, my freinds, to the head office. The fish rots from the head.
The idea that administrators might be a "problem" is novel just because normally in a bad shop with failing senior management you just get bad developers... bad everybody. Because hiring standards are shit, because bad behavior and bad performance doesn't get anyone fired.
I actually do see specialization as a problem - but as an unavoidable one. As our work has grown in complexity over the years, specialization was inevitable, and we are just seeing the tip of the iceberg. But let me speak from the vantage point of a relatively well-managed shop. Here is what work is like for me.
We do have an IT group that "runs the desktops," making sure email gets delivered and wrangling windows and fileservers and so forth. They lock down the machines of quite a few people, but they are flexible and friendly - and developers (and anyone else who has a need) get full privileges on their own machines, and even on development servers if necessary.
Our backups run, consistently, on time, and well.
We have a Unix ops team (that encompasses our DBA) that is 2nd to none in my experience. They will ride your ass hard for anything you want to do in production - as they should. It's their ass if those machines go down, and that 2nd set of eyes has caught many a terrible thing before it escaped our development and staging environments. When we are testing something for scalability, they are in there with us, unleashing Solaris or Oracle wizardry, literally coaching better code out of developers, and generally making magic happen.
That in itself is a good snapshot of specialization working as it should - not insular, but aware of what's on the boundaries of what you own, and working as a team.
We have a complex security architecture that simply works. They don't make semi-montly changes to it, because they did it right the first time. DBA staff is a collaborator in your database design - my god, I can't imagine these people holding _us_ up. Its almost always them waiting for us to carry our leg of the relay race.
Our long-suffering QA department is strikingly overqualified and polite to a fault when we destroy their schedule and then ask ridiculous feats of endurance from them. Even when they catch some pretty dumb stuff on our part, which they do quite often.
We use good tools, often open source, but not out of doctrine - our choices won on their merits. Management is ready to throw out anything if it doesn't work. We are platform and vendor agnostic - advocates and zealots get put in their place.
We are very productive, and although we are far from perfect and are not all of us dream-team members, we do extremely good work. Our company is so spoiled, and I think many who are relatively new have no idea how lucky they are.
And why is all this? One simple reason. We have a good CTO, and he's hired and promoted middle-management who are good engineers. And that, pretty much, is all it takes.
The trouble in big companies is that you have absentee management who pick senior technology leadership without any sense of how to gauge talent, and pay no attention to their performance, almost literally until (sometimes even after) it has burned the company down. The old white men are by and large still prime representatives of the previous generation in terms of their ignorance of technology, and every generation's aristocracy has the same habit of being in flight over the Swiss Alps while the house is on fire.
One man's opinion.
Want to Know How to Cheat the GPL? Read On!
There seem to be a lot of admins here who are missing a point he implies early in the article, and which he does not sufficiently amplify:
I understand that those DBAs who understand the details of the database engines are worth their weight in gold.
My impression is that he is not talking about the sort of admin that is likely to be reading Slashdot on a Saturday. He should have repeated this statement in each section, to make it clear that there are good and valuable admins in every sector.
It is my experience that we are now 60% over-administrated.
This is also a bit too understated. He implies at a few points earlier in the article that he works for large enterprises. If you've worked in a large enterprise, you know that in such places, the paper-pusher admin to skilled admin ratio is 60/40 on a good day, going downhill, with a gale-force tailwind.
The people he's attacking are (for example) the sorts that engage in "security by chewing through the wires" - putting a firewall at every major network nexus, shutting down all traffic, and demanding written justification and properly red-tapified authorization for every open port. Don't get me wrong - default deny at the perimeter is a must, and default deny on some nexuses is the right choice. OTOH, for example, a default deny firewall between the developers and the appservers has a very real cost (EG: waiting six days for paper to clear before being able to turn on JMS). He's not even saying this cost can't be justified - he's just saying that cost has to be assessed and charged to the administration budget, and it is currently charged to development:
the true cost of administration must be accounted for when totalling up the cost of any project.
The point he's making is not that administration is bad, but that because management has lost it's grasp of development, and because they can grasp the paperwork-and-authorization oriented style of administration, management has given administration more power than is optimal. There's a balance that must be struck between wild-eyed developers and stodgy administrators - safety and speed are both valuable, and they are naturally at odds. In major enterprises, the balance is askew and getting worse, because the practice of software development is evolving so rapidly. Likewise, administrators are quick (and right) to point out that in smaller companies the balance is askew in the other direction.
I think his main point is that bad admins are a bad thing, and that management often sees bad admins as good admins, because bad admins generate more sturm und drang. "If people are complaining about things being shut down, there must be some security goin' on. If they're not complaining, what did we hire these guys for?"
So unruffle your feathers - if you're not allowing your developers to host outside accessible websites on their desktops, he's not talking about you.
OTOH, if you don't know enough SQL to understand a script that has been submitted, and you reject it because it is not indented properly, remain ruffled - you are the problem.
Stop-Prism.org: Opt Out of Surveillance
1) The list of so called administrators here is ridiculous, you can't include network/system administrators in with package vendors(what ever the hell they're supposed to be) or blame the whole thing on J2EE because it has architecture problems, that's not admins fault. As a side note, forcing developers to do things they don't want to(document code, plan before they start etc) is a necessary evil since most coders including myself don't want to do these things.
2) The idea of developers doing their own administration is to be honest laughable, if this guy thinks that administration slows down development imagine what it would be like if the people who were supposed to be coding were doing it, even if it didn't take all their time they'd be focusing the results on their needs not on the needs of the secretary next door.
3)As for getting root permission on anything or being able to install your own software. Being able to code does not make you qualified to run a system even an internal test system(assuming you want it connected to the internet). Even on a windows box giving root access to anyone(even developers) can be a serious nightmare. In my experience fixing the computers of people who know something(ie developers) is much worse than doing it for people who don't since other than the usual crap they don't futz with their pc's much. Supporting a machine with random software and random configuration is hard enough when it isn't mission critical, ask tech support.
4)As for Roaming profiles, the reason people set them up is because that way, when you hose your machine(which 90% of people will do either because of ignorance or bad luck) they can just roll you out a new one without having to recover the data from your old one.
That said any system administrator who tells you "it's only two weeks worth of work" under any circumstance beside an act of god(there is no reason you shouldn't be able to get your data back but you can't) should be canned and even under the act of god circumstances they should be apologetic.
I agree that delivery of a mature stable system is the number one priority. Unfortunately this is often in direct conflict with the expedient goals of developers, who say things like "just give everyone access."
The only real problem in the article is incompetent administrators and incompetent management. Interestingly there are no incompetent developers in his world.
Delaying a multi-million dollar project is never okay for a competent admin. Competent management would never allow such a thing to happen either, or such an admin to remain employed. Missing backups should be an instant pink slip too.
Unfortunately most developers are no more competent than most management and most admins. Most people are mediocre by definition. Paranoid admins are no worse or more common than managers who don't do anything but protect their fiefdom, or developers who know nothing but driving a particular gui.
In technology we'd all be better off if we understood computer fundamentals better, but we can't all do that. Very few of my developers have any acquaintance with microcontroller programming, but studying that is a part of my understanding of how computers work. Most of them have never touched Unix, or any free tools either as far as they know, but knowing those makes me a better admin.
Dealing with multiple administrators is a pain. Modern systems are large and complex, and complexity increases exponentially with size. You're going to have to deal with multiple administrators, and modern projects need a project manager.
I worked in the office of the network architect for a fair sized company, and he spent hours at a time on calls making the network work, sometimes days. He also implemented a VOIP architecture that saved the company hundreds of thousands of dollars in the first year. None of the developers would have been able to do his job. They didn't have the technical expertise, nor would any of them have been willing to troubleshoot the global WAN around the clock.
One director who wanted the NetArch to make a client's VPN to work right now, threatened to call the CEO because it didn't. Never mind that the client had refused to give us any of the information we had requested (weeks before) to make it work. We had done the best we could, and the final problem turned out to be one with the client's configuration, which we weren't given any information on. One client finally agreed to call their tech support, who pointed out that they needed to use a special acces point coming from NATted environments. Simple for them, impossible for us.
A friend worked in a company without a dedicated admin. This startup full of brilliant coders got their FTP server cracked, and someone downloaded all of their work. Maybe it was one of their competitors, maybe not.
Backups are a pain, and none of the development servers I've seen were actually backed up regularly by the developers. These were the same folks who insisted on running Visual Source Safe without licenses, and just didn't have an administrator, so when they had to fix the database or roll back to an earlier version so that people with Macs could use it, they were out of luck. They never bothered to learn to use their tools, so they encountered the same problems over and over again.
When they wanted firewall holes for AudioGalaxy, or for me to give them software that they were unwilling to buy, or when they opened another virus infected email, I was at fault. When the dev servers failed, even though they existed solely to give the developers total control, it was my fault. When the VP wanted a deleted email back, we had backups though, unlike the development servers maintained by the developers themselves.
I may sound cranky, but I was always cheerful & respectful of my developers. I knew that they just wanted to do their jobs, and didn't know how things worked.
The author reports that many developers feel that administrative burdens are halving their development efficiencies. That's meani
Assembly is the reverse of disassembly.
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.
This article contains some truths but I think assigns blame incorrectly. The admins are "just doing their job." They were put in these micromanagment roles by the "powers that be." Part of the draconian procedures for backups, roaming profiles, antivirus, etc., are a direct result of using Microsoft products. The sysadmins MUST act this way to protect a shoddy infrastructure. Lastly, the comment about a developer needing specific rights to install software may apply to the author but this is not a universal truth. I worked as lead tech on a development project and was astonished to learn that a lot of programmers know dick about how to actually use a computer. The author accurately targets the symptoms but misses the root cause.
Humm. The problem is an old one. Not just a rise but perhaps the perception, as our developer friends ages, of a world bigger than just his development community. The problem is that his development work is just one of the many areas of a company which must function to enable the company to function.
The role of the administrator(s) is to ensure that all users are able to complete their work with the minimum of fuss and the maximum of security. From whom? Well, competition, disgruntled workers, idiots, worms, virus' etc etc etc.
The list continues to grow and the developer is not generally aware, nor should he be, of all the areas the administrators have to cover.
In the end it comes down to communication and perhaps the tone of the article relates to the problem well. The author is not able to communicate politically. Calm down. Talk WITH the administrators and not TO them. Try to understand where they are coming from and maybe, just maybe they will climb down from the pedestal on which you place them and be able to help you.
Developers whine about not being able to willy nilly install anything tools they desire, code in the "cool" language of the week, or drag in any middle ware which is fun for them to playwith i.e. (Tomcat, Jaguar).
.NET using CORBA, XML and exotic middleware, however they don't understand it, nor do they have any desire to feed and care for it. This results in yet another orphaned system that will probably need to be rewritten in just a few years since there will be no one around to understand it. However, nowadays it looks like the next re-write will take place in India.
The developers then work on their little projects, get them finished, and DUMP IT ON THE ADMINS and RUN AWAY (off to the next exciting project). Yes, the developers are typically able to coble together their cool Java Beans J2EE to
Unfortunatly, for the sake of the users and the corporation, the Admin ocassionly has to say, "No". Believe me, I'd like to let everyone install EVERYTHING and play all day and all night. Innovation, innovation, innovation to the extreme. And that security stuff, who needs it. Just turn off all that annoying ActiveX security for the ease of development. We wouldn't want to slow anybody down. Also, disable all the Java security and let applets connect to and from anywhere. Ditch it all, after all the world is a safe place. There aren't any bad people out there creating hostile ActiveX and Java applications, plus the firewall and virus checker will save us, right?
Systems must function for the sake of the customer and the customer's business. For this to happens, there must exist a well understood development framework and compotent people to manage and maitain the framework. Without this, you are in the wild-wild west of systems and are heading for the land of perpetual system rewrites
I am an ex-developer admin so I work with my developers to help them logically design their applications and database objects. I even tune their SQL, but I resist letting them go off in "cool" direction of the week, just so they can add a new line to their resume and dump yet another one-off application on me which is guaranteed to misbehave and be nearly impossible to upgrade.
Everything this guy has to say is invalidated by the fact that he runs a company that offers full-fledged consulting services to - you guessed it - other companies!
This is like a Ford exec writing about how Chevy sucks. Taken with a grain of salt, it is.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
So I RTFA, and the whining author works for a company called Javelin Software. Who remembers when Javelin was the Lotus 1-2-3 killer-in-waiting? Another great piece of software that didn't catch on. I even think if I poked through enough old boxes, I could find the prospectus for their IPO.
background:
A small company. I was in charge of the web servers at the site. They were running the code from the engineers. Engineers would build it, I would put it on the servers. Not quite release engineering, but close enough.
Engineer: this code needs to go on the server
Me: I'll put it on my test box, thats built exactly like the web server at site. (There is also a box like this I made for engineering to do the same testing. )
Engineer: Just roll it to the site.
Engineering Manager: Put it on the site.
me: I'll test it.
me: Did you know that your code is broken and that rolling it to site would have taken the site down?
Engineer: well we didnt test it on your box.
me: you mean the one with the documented process and the test box in the lab?
Engineer: it works on *MY* pc.
And there you see why an admin is helpful.
Processes like:
A unified (Ghost/Jumpstart/Kickstart etc.) Image.
Requiring Testing done on a known good configuration.
Software in X-Ray machines must undergo
FDA and HIPPA reviews and requirements.
Soon FDA will require IS9xxx or so for
the software also. This medical device
software gets alot of review and control
in development and release.
It sounds like this guy has had some bad experiences and therefore infers that it is the case for all of IT. I must say I'm a bit a affronted by his sweeping generalisation that IT admin is out of control.
:) I deal with folks like him in my work at the moment and I think it gets down to having them trust that you know what you're doing and getting out of their way.
I currently look after a team about 100 developers, testers and technical writers. The situation I walked into was one where each software group had control over hardware budgets, admin, the whole shooting match. Needless to say it was an absolute mess. Permissions were all over the place, NFS and Oracle servers haphazardly brought up, no fault tolerance, poor performance and reliability, the list goes on. I took the approach that my job was to help these folks get software products out the door as efficiently as possible. With that in mind, I sought to make sense of the environment and let the developers write code and the testers test it. They still had some control over day to day stuff, but I manage their total infrastructure for them.
This involved retiring unneeded systems, consolidating storage and servers, upgrading some machines, implementing some proper change management, auditing, performance monitoring, backups, standard system images etc etc. We are not there yet, but needless to say that there has been a significant improvement in the last six months. The coders seem to be happier and the infrastructure is more stable. That sounds like a win-win situation to me.
I think the key for any admin is to make a partnership with your users, understand their needs and address their pain. I agree that some admins rule with an iron fist and have users cowering in their presence. This is counterproductive. But so is having no admin staff in a development centre. If the chance arose, I would actually like to work with the author of this article and perhaps help ease some of that pain
Yes, there is absolutely no need to be semifascist when it comes to systems control if you have people, including developers, using resources responsibly. But for admins, believing in the Good User/Developer(tm) that always knows how to behave is a daydream. There are both kinds of developers, nice and competent and dorks, too, and you don't want the dorks to harm the often business-critical servers you are in charge of.
Moreover, blaming the sysadmin for systems being overloaded by too long backups is easy, having the cheap management to invest in more capable gear might be not so easy, from my experiences. That oh-so-badly managed db server almost crashing under its load might work more smoothly if either the software and data design had been done more carefully, or if the CTO wouldnt have chosen the cheapest server without talking to the admins in the first place. And restrictive firewalling rules which keep the dear user or developer from using Gnutella might be seen as evil, but it might as well keep these ugly RIAA Cease&Desist letters from being sent to the CEO again....
The article describes a developer-admin relationship that is pretty similar to a bad user-admin-relationship. Apart from dealing with villain admins, work quality and efficency can be improved significantly through communication and understand each others needs and expectations.
And BTW, I wonder if outsourcing administration is mostly done due to bad quality of in-house admins, but rather to save money. This often reflects how poorly admin work is respected and valued through management, even the professional and good work, maybe because good admin work happens mostly behind the scenes. I know a lot of small companies that suffered badly from outsourcing administrational issues, mostly because the admin(s) who "obviously did not do so much during their work time, so we might outsource their service anyway" now were missing in the critical situations when you absolutely want a dedicated admin who knows his/her environment well.
So much for whining on the admin side.. .)
Witty, clever, and requiring hours of pre-planning. You went for the gold, and you got it. Congratulations!
Most ineffecincy comes from the programmers writing complex hard to maintain code that results in many defects throughout the project. This includes lack of comments, lack of planning ,etc. companies outsource because they can purchase engineers for 1/6 to 1/10th of the cost of a USA programmer, they are not more efficient but in most cases less.
The bottom line comes down to poorly trained programmers writting sloppy code.
If not for system administrators, database administrators and corporate security teams a 9 year old would be able to compromise every major company.
Engineers are notorious for taking short cuts that result in defects and poor security. Coupled with this the US computer science system does not teach software engineers how to test correctly, the training they do get is deadly wrong.
I'm the network/system administrator.
My co-workers, developers, love to install widget x, object y &c.. on the web server.
Purchase the stuff, install it and come crying after the hardware platform turfed.. none of them spent the time to ensure that anything was documented.
Yeah, we admins are the nay-sayers to incompetent, arrogant developers.
Rightly so.
I was the I.T. Director for a web development firm back in 1999. When I got there, the former administrator had allowed all developers to have root access and total control of the development servers. I fought tooth and nail with the development director to get this removed, but I was told to accomodate this. I warned the COO numerous times that not only did the developers not need root access, giving them that access was potentially dangerous. Everybody thought I was being paranoid.
Well, about a month later a developer was having difficulty with his JSP app and decided to not just restart Apache -- no, he restarted the entire server. About forty developers who were telnetted in lost everything they had been working on (periodic saves? "What's that?" says a developer). Total cost: about six hours of work per developer. Dev's were billed out at about $200/hr back then, so 180hrs x $200/hr = $36,000 lost in one day, not to mention putting the project behind schedule. There were other incidents of programmers deleting other people's code. In one case a developer took the opportunity to push an outdated build of code onto a production webserver and hosed an entire database. It took the I.T. team about half a day to get everything restored from tape, during which time the webserver was down.
I took my case to the COO and got root yanked from the developers -- all of them. They whined, they bitched, they moaned, they screamed that they'd never be able to get any work done, they had to have root or the world would end.
Well, it didn't end. We used sudo to give them the ability to do certain things, but the I.T. department kept absolute control over the box otherwise. We made no friends in the development department (we were hated, to be frank), but oddly enough projects continued to get done on time, on budget, and without any pain.
Far from it being the I.T. department that's the control freak, it's the developers who like being the control freaks most of the time. You want root? Fine. You just better be able to explain to me why you need root in a way that makes good business sense, and why there's no other way under God's green Earth you can do what you're trying to do without root. I've been in this business for almost twenty years now, both developing and administrating, and I have yet to hear a convincing case ever why a developer must have root access. This is, of course, assuming the I.T. staff is competent and up to the task of managing the box, but if they're not then you've got much larger problems than just who gets root. In the end, the I.T. staff gets held responsible if a box goes awry or gets fscked up by somebody else. If they're responsible for it, they damned well ought to be in charge of it, and that includes deciding who gets what kind of access.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
So according to the article, having a seperate sysadmin means:
Slower development times
Increased communication overhead
Increased dependencies
Slower rates of change
De-skilling of the workforce
Extra manpower needed
More paperwork
They forgot to add:
Servers set up correctly.
Servers patched
Less hacking incidents
Coders unable to browse pr0n and get away with it...
Of the people who work on my projects, it's pretty clear that the ones who understand (read: do) both programming AND administration are by far the most useful.
I am a student at a public school. I take a lot of programming classes, and our sysadmin is doing everything that is possible top prevent more, erm, destructive students from messing with hsi workstations. I find that we have to find workarounds to security measures all the time, be it uploading a file to email or simply running the programs we just compiled.
this thread doesn't seem to get at the real issue, and the author only touches on it. are you a profit centre or a cost centre? most people don't consider this, and it's human nature i guess to think that your view of the world is the most important.
any argument admins can make against developers, developers can in turn make them about their end users in a typical enterprise. the bottom line is that you serve your client as best you can, and eventually you get to the money maker. if a user can't make the widgets because an app doesn't meet their needs, they get frustrated. if a developer can't meet her deadline because she is tied up in admin-related stuff, then they get frustrated. and all of it is counter-productive.
so please, before another admin posts an "i am admin, hear me roar" comment, realize that the servers your company bought are there primarily for getting business done, not to be administered. also, i'm not saying the developer who wrote the article was correct, but he made some good points. it is wrong to undervalue an admin and say they are unskilled, etc, but if business isn't getting done because the policies are too tight (they just seem to get tighter and not looser?!), then there is a problem within that company.
as companies get bigger, it is very difficult to preserve the environment where everyone has the same agenda - to get the company's business done.
Have you seen Ironstayn vs Supergovernment yet?
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?
:D
ClearCase defaults all checkouts to reserved, unless someone else has a checkout reserved, in which case you check it out unreserved automatically (though this, like most things in ClearCase, is configurable). The point of this is so that you can do this:
1. Developer A checks out version 3 of a file (Reserved).
2. Developer B checks out version 3 of a file (Unreserved).
3. Developer A checks in his work, making version 4.
4. Developer B tries to check in his work, but ClearCase, knowing his checkout is unreserved, makes sure that he merges his work with version 4 (from above), so he doesn't mistakenly blow away Developer A's work.
Simple, eh? Yes it is. Hire a good administrator who provides good support and training and you'll be all set.
Hmm heres what I remember of the industry from 10 years ago.
.MSI, RPMs, .pkg, Encap, CFEngine etc.
1: Users did not expect to have internet access.
2: Most Users were more tied into novell, and had limited access. It was common to keep things on a file server, especially if they needed to be backed up. Back then, your PC was not backed up.
3: If there was "internet access" it was that they had e-mail. Things like Mosaic were still catching on in popularity.
4: Few users had a TCP stack installed on their machine, in most cases it was IPX/SPX (for novell). In Some cases, users would use SNA to connect to their ibm minicomputers, and in some cases it was TCP/IP. Windows for Workgroups was out at that time as well on Netbeui, but "3.1 Advanced Server" wasnt anything to recon with until 3.5.
5: If you maintained a network, you maintained a 10MB hub/repeater/concentrator. There were a far less amount of routers and configurable switches. You didnt have to worry about full duplex, half duplex (10, 100, 1000) etc. The biggest problem was, what IPX frame type you had, but a well configured server had all of them configured.
5a: In most cases the router was the server. (novell IPX Routing, suns running gated/rdisc etc.)
6: Virus protection was needed, but were not e-mail borne, and were more likely to come from floppys from home.
Now, lets see what has happened over time.
1: The popularization of TCP/IP. Yes, now every desktop has it. All the functionality is delivered by it.
2: the popularization of the internet, the browser etc. Now every tcp/ip enabled desktop wants to get to the internet.
3: The downfall of IPX/SPX based file serving. (sorry novell).
4: The popularization of NT Based file servers, and file serving appliances (Netapp etc.).
5: Concentrators became switches and are more complex.(10/100/1000, half/full duplex,STP).
6: Routers are now common at companies. They are dedicated appliances. They do hsrp/VRRP etc.
7: Greater reliance on PCs. Now you have to provide your users with a higher level of uptime. Due to the higher reliance of the internet and the moving of more features to the network (that was done before in a non computing fashion).
8: The appearance of NAT.
9: The complexity of the users Daily apps. and the PC. Its no longer win.ini and sysedit. Now its the registry HKEY_LOCAL_MACHINE and a good amount more. Its not windows 3.1 with dos 6 running underneath.
So over the last 10 years, the job of maintaining a network and the servers has become more complex.
Now maintaining the switches, requires someone qualified.
Now you need someone to understand routing.
Now you need an internet connection and security.
The File Server now needs more availability.
E-mail is now mandatory, and it needs to access the internet.
Virus scanning while needed before for checking the floppy that came from home, is now needed to check the internet gateway, each PC, and the file server.
Additional complexity on the User PC, The OS etc.
What was once a simple job, where 1 person could have limited knowledge but still do the overall role now requires someone with more experience or more people.
--------------------
So as complexity increases administrators have tried to lighten their workload by getting things streamlined:
1: cookie cutter OS builds (jumpstart/kickstart/ghost etc.)
2: Cookie cutter software installs:
3: DHCP/Policies/Profiles
Then there are installs of necessity:
1: Virus Installs on PCs.
2: The idea of "deny all that is not allowed"
Now, do some things go faster as a result?
Yes. - admins no longer have to create a BOOTP entry for your unix box, or assign you an IP.
Yes. - A replacement PC can be delivered and set up with a company image quickly
Do some things go slower?
Yes. - now you need firewall rules or you need a 1 to 1 NAT.
Overall technology is not getting simpler, it is getting more complex.
Developers are doing increasingly stupid things like:
Take data from A mung via B load to C.
B mungs data again to load to D.
B reloads back to A from D the data that orginally comes from A.
so
A->b->C->B->D->B->A
yep closed circuit and data is unrecognizable.
Did I mention A and D are secure and C is not? B is quasi because it is just a Informatica Data munger. And that B is the MOST BUSY network user, 1.1 to 1.5 GIGABITS average usage during peak hours? Had to trunk 2 interfaces to get the bandwidth, plus a secondary network to handle local data loads.
I call it either plain stupidity or someone cooking the books. This is all billing/actuary data...so you figure it out.
I could go on and on and on with all the stupid things developers do that we stop as Sys/DBA admins... but that would be a whole new article.
Suffice to say DEVELOPERS need to think about how they will impact the PRODUCTION MONEY MAKING SYSTEMS when they develop. Because our job is to protect the revenue stream, not make it easier for you to code away.
Never answer an anonymous letter. - Yogi Berra
Large corporations are increasingly going to be less likely to do in house development. I work at several, and, given the choice between make or buy, they will invariably choose buy. If they decide to make, they will invariably choose an outside firm. Even for small in house projects, they will generally get second and third opinions from outside consulting firms.
The issue here is risk and politics. In an in house job, there's only one market for a product, the firm itself. Many of those people are not market savvy, and projects tend to get bogged down in politics. If it is an outside job, then, the firm gets the solution but avoids a lot of the internal tensions. So, managers and administrators will invariably choose outside software.
What does this mean for the Open Source movement? If corporations do not want to internal development, then, the notion of developing common open systems via the consultancy model can take a hit. On the other hand, open source can lower the costs of developing vertical market applications for smaller companies.
For me, its an interesting problem because I have a system that I probably would like to open source, but, because it is vertical market, the open source community at large won't be receptive to it. On the other hand, a proprietary solution carries with it the problems of propreitary software. Not only do I have to write everything, I have to test it to, and the closed source product is not nearly as good as what a peer reviewed open source system could be.
I think that the next phase of the open source world is to go after vertical markets. To do that, there need to be open source places on a by industry basis, and people willing to participate. That way, the advantages of open source can be fully leveraged. Companies otherwise afraid to take risks can be assured that their own risk is much smaller. Vertical market open source solutions would force vertical market standards.
The question is, where to start? I dunno. If I were to open source my commodity server and GPL the whole thing, where would I put it in such a way that other open source people in my industry could see it? If such a place existed, no doubt I would do it today. But putting stuff on source forge is too general (not organized by industry), and, even getting money for a CVS service seems difficult. I just don't even know where to start!
This is my sig.
I'm currently a DBA/SysAdmin for a small shop. (7 devs/ 3 admins) I've been working here for 10 years. This are the rules I live by.
1)Provide the best development environment you can.
My company is not fond of buying development boxes. I see them as an absolute necessity. I scrounge hardware, software, and what ever else I can to make sure the devs have what they need.
2) Give appropriate access.
Dev's need root access to the development box and DBA access to the development instances. They get what they need as soon as possible, I don't get interrupted to restart Apache 10 times a day. Dev's don't get root to production machines. Processes are not run as root.
3)The BOFH doesn't work here
I'm a service provider to the devs, our end users, and ultimately our customers. It's not a kingdom, it's a big freakin' amusement park. My job is to make sure the rides all work, the popcorn is fresh, and the soda is cold. I will install tools, modules, kernel patches or whatever else you need. All I ask is that you test the heck out of it before you ask me to put it in production.
4)Commumicate and Collaborate
Tell everyone what you've done with performance tuning and why. Explain why you've had to freeze database changes. Tell them why you had to disable port xxx. Ask the devs for help with those nifty widgets to read the database system tables. Send them the SQL performance tuning tips you find so the SQL can be done right the first time. Look for ways to make the devs life easier. It will make your life easier, too.
5) Stay Professional
Projects get delayed. Things break. Tempers flare. Keep your cool at all times. (I have a very hard time with this, BTW) Do not add to the problem. If you screw up, admit it, and fix it. Now. If you find a dev's mistake, handle it in a diplomatic and low key way. Nothing sucks worse than an us vs. them IT department.
Blue
My wife is like Unix. Lots of commands. Lots of arguments.
I'd like to thank the author on so many excellent points. He probably knows that this article will be met with flame.
Unfortunatly, I have a parallel set of horror stories.
I think there are a number of factors have brought this situation around but the predominant factor is the Peter principle on a mass scale for management at technology companies.
This has happened as a symptom of fighting between the technologically challenged and the technologically gifted continue because of failure to communicate. Software engineers (any engineers) live in the reality warp between social needs and scientific envelopes. Hence the difficulty for some managers to truly comprehend what engineers are saying. For a software enginner to be successful, they must bend their reality to meet artificial and often nonsensical goals. When a software engineer meets a near absolute issue, it is often impossible for them to communicate the level of risk. Hence the technically challenged management is unable to comprehend the gravity of the risk. Hence the ultimate breakdown of trust.
Example scenario:
IT administrator wants to "be more secure" and rules on creating a firewall. (often for selfish purposes - i.e. to attain experience) Engineer's job just got harder and asks IT guy for reasoning. IT guy responds with a "management told me" response. Engineer grunts in disapproval and moves on because the past experiences with discussing this with management have never been fruitful. As a cancer grows so does this process and finally, no-one does anything.
This has nothing to do with large companies, I've seen it happen in small companies as well.
I have managed many software development teams in large and small companies (as the director of SW dev) and I often have had to simply ask that my engineering team do all the administration. It's amazing how a bunch of smart developers can take the job of 5 administators and turn it into an hour a month kind of duty. Hence, I now look for developers that are skilled in all aspects of computers, from writing software to being able to administer an installation of machines.
If you look at high profile examples (like *both* Space Shuttle disasters) you can see that this problem is endemic in the a bureaucracy as one of the evolutionary stages. Unfortunatly, if the management at the very top of an organization can't understand this, the outcome is inevitable.
Here are some URL's and you can see what is happening in the world where management and engineers fail to communicate:e sson.htm a manujam.errors.html
http://whyfiles.org/185accident/index.html
http://www.colorado.edu/AmStudies/lewis/ecology/l
http://news.uns.purdue.edu/UNS/html4ever/031120.R
We are a software development company for crying out loud! The IT fascists tell me I cannot use a CD burner; they tell me I don't need to replace my dead laptop battery; they will not disable the flawed spam filters on my mailbox even though I don't receive any external mail at work; they want me to go through them for training on perforce even though I think I get the concept as a developer; they want to pay $$$ for VMWare at our company when we get connectix for free via MSDN (to add to their power base at the expense of new equipment); they dont want hubs at our desks yet they refuse to give any employee more than 2 network drops; they have tried to steal my old computers from my desk claiming I don't need them; the list goes on!!
So ultimately, most of my time as a developer is spent getting VPs and Directors to override the IT pinheads. Very efficient...
SCO: 800-726-8649
Verisign: 800-361-8319, 888-642-9675
Diebold: 800-433-VOTE (8683)
I think essentially you have sysadmins reacting the way people do when they feel that they are not being listened to, that their needs are not being considered, that they're being coerced and bulldozed.
Of course it's not nice to overcompensate and retaliate. But before pushing challenges and change into another's environment, we should look and listen carefully and see what hot buttons are being pushed, and then proceed in a way that works for everyone. Try a little sympathy and putting yourself in the other person's shoes... the syadmins after all are the front line taking the complaints when software develops bugs that the developer didn't catch before pushing out an update.
As an administator, I fully understand the need for everyone to 'get their job done'. I need to 'get my job done'. I need to get my job done with the resources management and projects. Without that support, I end up having to manage less and less and do more and more. Sound familiar out there developers? I truly wish everyone would take a step back and realize that companies have been holding back because of budgetting and spending in the late 90's. They contracted back to bare bones. My department of Apps, Admins, Project manager, went from 22 to 8 three years ago. We were supporting 600 people in all aspects of IT at 22 people and went down to 8 with the deflation to 350 people. Now, through 3 years of inflation of needs of support services, we are still 8 supporting over 700 people with another 100 on the way. We waited 5 years for budget approvals to get new server equipment to support the general population. What we needed was the general population to appeal to management to bring the support back to appropriate levels so we could do more than fire-fighting. Yes.. we are fire-fighters... do you scream at your fire-fighters? Maybe next time it won't be so easy to rescue you.. because they are busy rescuing someone else. At any rate... this was a rant I've wanted to get off my chest.. you've gotten yours.. let's get back to getting the job done. Perhaps management will dedicate the resources needed.
I think to excel in either you need to understand at least the issues dealt with by the other.
Manipulate the moderator system! Mod someone as "overrated" today.
Hey, as long as the boxes are secure, and the developers really do know how to admin the boxes, then maybe it's ok.
On the other hand, I've seen developers try this strategy and create a huge security hole in otherwise secure networks like this:
- Developers set up two boxes for development. Fine.
- Developers don't patch the system. Developers want to focus on development, not on patching systems. It wasn't a super-important network, so maybe this acceptable.
- Developers wanted access to every port on the system, and therefore allow access to every single TCP/IP portn. In reality they just needed access to the SSH, HTTP and HTTPS ports, and a few unprivlidged ports.
- Developers couldn't figure out how to get SSH to work, so they all used telnet and rsh.
- Passwords on the subnetwork are the same as the passwords used on the rest of the network
- Nobody told the sysadmin about the secret network, for obvious political reasons.
And then some genius hooked up a wireless access point to the subnet without any strong authentication.
Bam! Hackers crack into the network, because:
- WAP becomes an entry point into the network, around the firewall.
- Unpatched system has dozens of vulnerabilities
- Unencrypted traffic on the network exposes everyone's password
- Passwords work everywhere on the system.
- The network become a base on which they can attack the rest of the organizational network.
- Organizational network became base from which crackers can attack other networks.
Shit gets cracked, passwords are decrypted, crackers replace login scripts and 'passwd' with their own fun utlities.
The developers were clueless, and had no idea the attacks came from their network. This is because a simple network has no intrusion detection system, no traffic monitor, etc.
"Can of worms? The can is open... the worms are everywhere."
most programmers (and engineers) actually want to make something work (we *like* it). naict, most everyone else wants to build an empire or has some other agenda. so rhis result is not surprising.
xp was invented to combat this tendency at the development hierarchy level. maybe someone needs to invent xa?
vice chair orange county java users group (ocjug.org).
That's what I usually tell developers that want some crazy stuff, like applications running as root or some other assanine thing. Go over my head. If you can convince the CIO that our customers absolutely need the functionality that your hackneyed application provides, along with all of the problems to the system that it creates, I'd be happy to put it in for you.
That's what it's all about, providing functionality to the user. If there's a business case to do something wrong, then of course we'll do it. No question. If you can't make a case to the CIO that they're comfortable with then you'd better be thinking of a different way to do things.
What if it is just turtles all the way down?
Under the article this gem:
Normally I would accuse an author writing something like this of smoking something illegal in most corners of the world, but this is such a pile of steaming fecal matter that I just have to ask what planet the author has been living on, and why couldn't they just stay there?
OK, gotta get back to my code now.
I have been a System and Network Admin. Many programmers say i'm probably the coolest one arround. All I tell them is I'll cut as many corners as I can, but the rules are the rules, and they are there for only ONE reason, to save you an the company. And of course there are the other rules that companies impose that i can't even get rid of, but we have to live by them... Those are the rules I fight against for sanity and for the pure sake of common sence...
Programmers and Office type like me because of the pure common sence, nothing else.
I guess the author is a good developer and never had to deal with new software rolled in that broke everything else, used 100% of the CPU, filled up the filesystem or caused serious database lock problems. The lesson is that smart people in any role can do a good job and stupid people will usually be a disaster no matter what they choose to do.
Some developers like to consider the computers on which their software runs as unlimited resource pools ready to be harvested and they always think their software is more important than everything else. If the machine has to sweat to get it done, so be it.
On the other hand, there are very good development teams everywhere. They are usually an exception and a sensible system administrator or database administrator will (as he or she should) give them more leeway.
Disclaimer: I'm a DBA.
I may be worse, he could actually know what Putty was and erase it because only an evil hacker would want to use these command line things.
There is little to nothing you can do to lessen security in the average big corporate set up. They all have Windoze on the desktop recieving email with Lookout and brownsing the net with IE. What bigger set of holes do you need? Who's going to bother setting up an atack point in WAP distance when they could send your secretary an email instead?
Now, I have to ask you what kind of developers do you have that can't figure out ssh? I don't think such a beast exists. It might be very hard to get such services working on a Microsoft system, but why bother? Corporate policy mandated by clueless admin?
Friends don't help friends install M$ junk.
should fit on one whiteboard.
Sometimes we cheat, and take a picture of the whiteboard with the digital camera before erasing. Just in case there were good ideas on there that we might want later.
"If you think you have things under control, you're not going fast enough." --Mario Andretti
this article clearly suffers from myopia. If the only thing that mattered to a business were coding then the author might have a point, but it's not. It's running a business. To run a business more is required than the production of code (e.g. security, reliability, relevance, etc). The trick to running a company is not producing code. It is getting everyone to go in the same direction, the direction of producing products that people will buy. Often it seems that some people that are clever at producing code think that their cleverness extends outside of their field. It doesn't, necessarily. Get over it.
Yes, administrators can cause a hit to productivity (good ones can actually help productivity), but there are other gains to be had. And any person responsible for planning software development should of course take that into account.
Yes, there are also a lot of administrators who don't know their ass from their elbow, but that is a function of the person not the position. Administrative overhead should be kept to a minimum, of course, but administration is a key component to developing a stable, scalable, mature company.
This article is little more than a libertarian fantasy that just demonstrates why coders need to have administrators (and supervision). It sounds like coders are looking for someone to blame for the whole offshore fiasco. The offshore fiasco is in part due to coders' over-aggrandized opinion of their ability and place in a company as well as the obscene greed of CxOs and shareholders. There are two sides of the issue.
The bottom line is that if coders want to produce code unconstrained by any external source, then they should do it from home on their own time for open source projects or their own projects, but if they want to have a job at a successful business, then they should grow up, increase the scope of their perspective, and learn to play well with others.
Please note, these observations only apply to coders that believe what was written in this article. I have had the privelege of working with many talented, mature, and highly productive coders. I hope they are the norm rather than exception.
The author of the article is right on some points, especially the "admin does what they have to too keep their job" point.
Politically speaking, being a sysadmin is like riding a k-mart skateboard in the middle double lines of the road with traffic buzzing back and forth both ways. You have to deal with everyone in the organization from shipping to the executive board and insulting the wrong person, even unintentionally could cost you your job. It's more than just a tech job, it's a lesson in both diplomacy and technology.
Developers on the other hand just have to deal with their project managers. They don't have to come into work in the IT persons uniform (polo shirt, jeans, pager, cell phone) They don't have to be the "first ones" in the office at 7:00am because the CEO is a workaholic. On the same note they are usually the last ones to leave, because someone absolutely positively needed something done "ASAP" although the trouble ticket was submitted at the end of the day.
I've worked with nice devs that were smart and understood what my job entailed. I've also worked with devs that were just so arrogant and annoying that it made me grow a grey hair or two. Either way they were always treated better than us corporate whipping boy gophers IT helpdesk people. I don't think the author has any place to bitch.
It is common in all fields for individuals to change the role they were hired to fill with the role they would like to fill.
The developers, programers, secretaries, etc., all have specific jobs which must be done for the success of the business. If a given security policy or IT procedure keeps them from doing their job, the policy must be disabled, until fixed, for the employee to do their job. Obviously this cannot be done in certain high-security situations.
This problem is seen outside of the IT field. My personal favourite is the 6 figure admin wasting two or three hours over a 5 cent increase in pencil cost.
Classic Buerocracy at work.
No code complete = 0 errors, perfect.
The poor dude is from big dumb corporate land. That's a place where developers are forced to run M$ windblows for ALL of their needs. Only have access to M$ "server" machines for code backup, have to use really crapy code management programs such as the two mentioned, continuum and clearcase, can't install programs except when a Lookout virus does it for them, and have to put up with read only databases. It's a sorry planet, but it's the kind of de-skilling big dumb companies think it takes to get the whole shit-ball ready to move to India. Companies like to make their employees miserable before they fire them. Chances are, none of the above is true offshore. No one who actually writes code would do things so poorly.
Friends don't help friends install M$ junk.
Most of this has been said in one way, shape or form.
:)
The biggest problems between IT and Engineering Staff are communication and planning. The needs of the IT Staff and the Engineering Staff are not the same. Where do you draw the line? Both sides are required to build a healthy balance.
What developers need is a controlled, understood, reliable environment - not something that changes at the whim of a developer.
Now let me look at one of the influential project managers' events recently.
"I want to install this free problem tracking tool" he said. Word spread through the company quickly and before you knew it, we were all using a tracking tool without process or procedure to support it. We used it on one major project. We decided the tool stank and had some big issues, so we ditched it (note: it should have been evaluated first against a set of criteria in a localised environment.. READ: rocket science].
Now we have to support this tool for the next 10 years. Who knows how to install it? Who knows how to review and interpret the data? How do you configure the tool? The developers don't give a damn - because it's not their problem. IT simply responded. One manager knows how to do all of this - and he won't document it. He's got another fire to start elsewhere for someone else to clean up.
On the other hand, i've seen an IT manager who would not allow us (Engineers) to do anything (eg. view the clock in the taskbar). Typically I wanted to know what day was next Wednesday - so I double click the time in the task bar to see the calendar. Eventually, this dictator was over-ruled but it took 12 months. Again, he was as destructive as the "influential manager". People spent a lot of time working around this dictator, wasting a lot of company time because communication and planning was not in place - not that this dictator would have listened anyway - he knew everything, just as the "influential manager" did.
No cowboys needed. Just planning and communication. Seems logical, sounds simple and IS simple. It just needs the backing of bosses who understand Engineering. Ok, ok, I had to ask for a miracle somewhere
I've seen both the best and the worst of having admins involved, and in not having them involved. About three years ago, my firm rolled out a web-based customer service app. My comrades in UNIX, NT and my network team were only told that they needed to provide servers and connections, not that there was a major application rollout. The first day the app was in use, I had the operations VP screaming in my ear that his agents at our remote site were unable to work because the app was so slow. We found that, because of the undocumented and untested requirements of the new application, the WAN usage at our remote sites went from under 200k to maxing out two T1 circuits. It took two years to finally get that situation stabilized by increasing our bandwidth several times over (increasing our costs) and spending several man-years to correct the application.
After a change at the CIO level, we now have multidisciplinary teams - programmers, admins, DBA's - working together to prevent such expensive oversights. The problem with the article is that it romanticizes the past. How many of us have had to live through DOS programs whose programmer assumed their program was the only one running? Today, more than in the past, we cannot afford to have walls built between the various groups in IT. The costs of failure are too great.
I think, therefore I am - Rene Descartes; I yam what I yam, an' that's what I yam - Popeye
When was slavery used to build up Germany? Or the Soviet Union?
So you never heard of the labor camps for Jews or the Gulags? You're not even a half-way decent troll. Go away.
This article is a joke, atleast where I work. In my experiance developers aren't concerned with important things like uptime and reduncendy. They will just willy nilly apply patches with out testing, or put the test environment into production. Half of my job as an administrator is just keeping the developers for screwing things up.
no, you CAN have 'cheapER, fastER, and better'. since the original was garbage in all three categories. You just cant have all three of "fast, good, cheap" on the absolute scale.
The reason for this being that, for whatever product you think is "fast, good, cheap", someone can always throw out the "good" part, and do it for less money. or at least, less effort, which is a part of properly computed "cost".
America didn't invent the car or the computer.
Germany has used slavery at various periods in its history, including the slave labour of various minorities - Jews, Gypsies, etc. - during WW2.
The Soviet Union was practically a slave state -- and that discounts the Gulags, etc.
Americans aren't lazy. They work longer hours than most of Europe.
And I'm not even an American -- I'm British. I just happen to be married to an American.
The most important point is that HR in most companies sucks. They hire the techies who lie most on their CVs, and the hirees get their friends to lie even more and join them. If HR ever realizes the people are useless they raise the requirements and get even more dishonest applicants. Coders do the same, but coders who don't produce get booted. Admins who don't produce justify themselves in meetings.
As an admin I often see other admins like this (and they are the guys contracted from other companies making $80/hr, not the peons). Consultants brought in to do specifics can be worse (though I've seen good and bad). Any admin who does not work with the developers when there are problems, and at least understand dev tools and third party software used in the company, is in the wrong role.
It is worthwhile having specialized admins (and testers, and support people, and developers) to make sure someone has responsibility for each area. I've seen enough companies where developers administer the systems, and there are always problems. The developers know what to do, but they want to develop, not administer, so the administration is done badly by a lot of people who don't know what other people are doing. Lots of "who setup X" or "who changed/deleted partition X" emails.
My last job was from a company made up of developers who thought they didn't need an admin. They got by for a few months, went live, and hired me. I spent my first two months just fixing stuff that was broken. On the other hand I've had stuff handed off from people who claim to be sysadmins that was almost as bad.
You got me into this! You were the ideologue! I'm only a poor assassin! - Twenty evocations, Bruce Sterling
As I developer I should not have root or admin access on the production machine I agree with this. I do not want to do half ass admin work. I don't even think I should be loggin into SQL server on a production machine that should be a DBA.
On my dev box I should do as I wish. Once the app is tested and productive it should be IT system folks taking care ofhe calls. If it is a true application problem a process needs to be in place so that developers can gain access to debug the app but this should be for a true app down problems.
This issue is not admins vs developers it is about disciplined work. If your shop is not focused like mine you have developers running apps on machines admins do not know what they do and you have admins writing perl apps that developers do not know of.
I laugh to myself sometimes when my manager gets
upset that some end user is having problems with my app. Then I am doing laptop support because some jack -off installed some spyware that f'd his network settings and can not log into my application. Our apps do have problems sometimes but 9 out of 10 it is people mistakes. So if management thinks it is worth my time so be it.
I hope their are companies out there that do disciplined work and are focused.
All of a sudden the trend to move to .NET
has empowered the Web developer into thinking
they are the demigods of the development world.
Thats why they need network admins, database
admins and security admins
Thank You Microsoft
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.
As a unix admin for a k-12 school district in CO I get paid about 20k less than my peers in private industry. The folks that admin the 17,000 plus desktops we have out at the schools are mostly teachers that know a bit about computers. The reason most of them are teachers is that you cant get desktop admins to work for 23,000 a year. The only reason I work for less is that I had 3 years as an admin in 99 when I started here and they district ignored the fact that I didn't have a degree in IT. Now I have 7 years of experience along with DBA experience. Things at this district are getting worse and pay is not getting better. Do you think I will stay when the job market gets better?
Firstly, admins digging and deleting your personal files, as some users have posted, have waaaaay to much time on their hands.
Secondly, has anyone heard of VMWare ESX? A developer can be root or whatever without affecting production or taking up too many resources. This is what we use.
Thirdly, why would a share not be backed up? Isn't the purpose of putting files on the server to reduce email bandwith and user administration? We have TSM go through and back up all the servers every night, with the shares holding a priority. Doing it any other way would be self-defeating for an IT department.
Fourthly, what is the problem with not having access to your own laptop? I can understand this for a secretary or intern, but a developer? When they leave the company, just reimage the drive! It's rather simple. Oh... they don't have laptops... man, I would hate to work there.
I said build up. Germany was already built when these things happened and so was russia. The USA was a bunch of trees and grass and the native americans and african americans were used to do all the labor, even the white house was built by slaves.
People don't exist to serve systems, systems exist to serve people.
I beg to differ. The Americans all want to be chiefs, and so they bring the Indians in to do all the work!
I beg to differ. The Americans who are losing their jobs don't want to be chiefs, they just want to do the jobs they were trained to do while getting their degrees.
... that c:\ is NOT the place to save configs and logs
... that "but it works in IE" is not an excuse for violating standards
... that a database account without a password is not the way to keep the program simple and hassle free
... that you don't install an os you don't know and leave all the services open just to see how apache works
... that "windows update" exists for a reason, and so do antivirus programs
... that not everybody has an 1600x1200x32bit display and a supercomputer to run their app
... that binary files have to be checked into cvs as, well, binary files
(and so on) - until then I'm not gonna trust them or give them any privileges.
I said build up. Germany was already built when these things happened and so was russia.
Your problem with language is as big as your problems with logic and history. Obviously, both countries are more advanced now - by slave labor. In contrast to your clueless opinion of American history, slavery was practiced in a relatively small section of the country. America was really built by poor immigrants, like my ancestors from Poland, who scratched the land for a living and asked nothing in return except the freedom to do so. Slavery was a short-lived practice that was abolished, although it was common practice in many parts of the world and still continues today. Again, go back under your bridge, troll, and stay there.
Why not just use software that does not need such expensive protection? At least you don't recomend anti-virus software on every machine, like the author complained of, but all such junk fails because they are all bandaids on top of flawed design. How can you say that Winblows can be secure after the last three years of internet destabilizing worms and viruses that mostly targeted big corporate networks? The point here is that they bypassed corporate policy the admininstrators, and maintained a their own little insecure network.
My point was that such a little network is hard to imagine but is still more secure than the whole big windoze nighmare outside it.
Friends don't help friends install M$ junk.
Zope
"I find it a bit ironic that Western culture embraces democracy and distribution of control (in theory), but tends to use an autocratic structure when things are critical."
From my 7th grade history class -- what we've got here in America is a system of checks and balances. For example, the House, the Senate, the President, and the Supreme Court each get a chance to cancel any bill becoming law. Only if all four of them approve will it stay in the books. Any sane manager would look at this system and say, hey, you've made it impossible to get anything done -- and that, of course, is exactly the point. We give governments power over us is dangerous to give to anyone, and that power should be damn hard to use.
Once the decision is made, though, it should be carried out effeciently, and that bit is done by normal chain of command, not committee. What you're pointing out isn't irony. It's the right tool for the right job.
So the role of network/system/etc admins is to do whatever the coders want and screw all other considerations and users?
Hey coders, I got news for ya. The reason the admins are out there is for the throngs of other users out there that are *using*apps* to do work that progresses the human race instead of cranking out rafts of buggy and useless shit every quarter to boost the bottom line. "Security and all other considerations be damned" is not the way to run a company. You coders would be screaming for a network admin's the first time you were hacked because he opened the firewall for every reason you gave them. You're already playing fast and loose with the company code, lets not fuck up the rest of the company. Stick to trying to work out the keyboard and file editor, code monkey.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
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!"
Where I work we were faced with a relocation. As part of the concessions management were willing to give us, was an extensive home-working option. Which we accepted. This of course lead the need for us to have a high-speed link to our office network.
The main network at work is outsourced and is ran in a very inflexible way, basically if you want to use anything other than MS Office, you're screwed. In the end the outsourcers could offer us 56K dialup on a pay-per minute number, with laptops we pay for (they own) and we pay a support cost, but as we needed to run linux, that would provide absolutely no support. Not exactly optimum, considering it would be relatively trivial to configure some sort of VPN over the Internet and just use cable or DSL in peoples home.
So this is what we did, we extended our existing seperate network for software development and now have a network we control ourselves and is far more useful and reliable than anything the corporate network could provide.
Of course, not all Software Engineers have the necessary skills for network management/admin, but a few of us do and it all works nicely.
Bad coders have an amazingly hard time getting a project to QA... they often miss their deadline by weeks, then QA fails them repeatedly for not having specs, not having use cases, for the program crashing on tuesdays or when someone types grape into a text entry box and it the program crashes.
So the programmers go to their boss, who is under pressure to get these things out and who is so clueless that they hired the bad programmer in the first place. The bad programmer gets their boss to try to end run around QA.
At this point the people who are in production see a political method of putting crappy software on their systems that they have to support 24/7/365 and they tell that team, "Up yours, follow process or we don't deploy your software."
At this point the bad programmer comes to slashdot to whine that the process is stopping them from deploying software.
And, yes, it is stopping them... but it only stops them from deploying BAD software. Which is why the process was put into place to begin with.
http://www.portlandwriters.com/Writing/nicholas_wi nlund/Flukes_Of_Nature.htm
That's what really chaps me -- not being able to access certain parts of the Internet because some moron couldn't imagine that I'd need to. Clear evidence that said moron didn't know what my job entails.
Of course, not being able to install arbitrary software on my development machines slows things to a crawl too.
The environments I've worked in (Tomcat, IBM's WSAD) don't require rebuilding the
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.
I, for one, welcome our new IT overlords.
...is which one of my co-workers contributed to that article.
there is no thing
what else could you want?
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."
I FOR ONE WELCOME OUR SYSADMIN OVERLORDS!!
Let me be the first to tell you who which rouge developers have installing non-standard unapproved downloaded software on their development boxes.
-- Given enough time and money, Microsoft will eventualy invent UNIX.
I spent 5 years as a Unix/Windows (mostly Unix, but Windows was creeping in) Admin at ISP in Alabama (HiWAAY).
... especially in this "please the shareholders at all costs" environment.
... but the admins are only asking for software to help them manage the extra load they are under.
I switched jobs in 1999 and now I work in the Linux/Unix software market and one of my duties is to keep the product in line with what the market needs.
The needs of the admins are not the problem. The ability to coordinate large software projects (StarOffice, Java Desktop System being the two I see the most on) and have enough resources to tackle it in a sparse economy are the problem.
It's not that the software devs don't want to do it, it's not that the admins don't need it (or don't know what they need and ask for the wrong thing, though that does happen sometimes), it is that today's economy has drained the software dev's resources, putting more strain on them from their bosses to do more with less, while at the same time forced a downsizing of the admin staffs, giving them the same strain from their management.
The two have met in the middle and are blaming each other. In the meantime the management is seeing the high value of "first world" currencies and instead of working to help either side of this battle are simply dodging the problem and outsourcing to help their bottom line.
Don't blame the admins.
Don't blame the devs.
Blame the people who made and make the bad (for us) money decisions
Or maybe you need to blame the shareholders
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Now, I'm not saying admins are smarter. Just that we know the system side of the equation. I now contribute to developer discussions and in the end, the app is fast, secure, and scalable. I can scale the servers without participation from the apps people. I can upgrade the OS with minimal involvement from the apps people. I can secure the machine without having to worry about stuff breaking.
I was just wondering: is there anyway here on Slashdot for the moderators to moderate not an individual comment, but the WHOLE DAMNED STORY as a troll? Because that's exactly what it is...
(Come to think of it, I wonder if Slashdot stories in general could benefit from moderation.)
This article smacks of the typical chaos that corporate developers often bring to the table. The author bitches that IT won't give him admin rights to his PC, yet he neglects to mention when he did have them the sysadmin was having to call him frequently to explain the high amounts of bandwidth being devoured by his system after he installed Kazaa. Or how about the help desk ticket asking if there is some way to block all the pop up ads when it turns out Mr. Developer installed Gator or some other [spy|ad]ware.
Yes, I'm a corporate bastard sysadmin. If I weren't a bastard the company would need four more of me to clean up the constant messes the developers create due to their complete lack of consideration for company resources. I'm not talking about the legitimate development work, either, but rather the pure crap that these guys do with their systems that end up introducing all sorts of malware into the internal LAN.
Just stop your bitching, and remember you're not at home. This isn't your network. It isn't your computer. It's the company's. Try to respect that a bit more, m'kay?
If by "schools" you mean colleges, then they're doing exactly what they should be doing: if you sign up for a diploma in "software development", you should not be taught "system administration" -- that's a separate diploma.
If by "schools" you mean universities, which are expected to give better rounded educations, then the problem is deeper: they should not be pumping out either coders or administrators, they should be pumping out computer scienticians who are capable of understanding formal languages and complex systems. Unfortunately most graduates seem to understand neither.
Domains, print servers, and clusters are the topics of college courses or certificates -- a well-educated student should pick them up very quickly on the job or in their own time.
Oh, so what's my B.Sc. on the wall?
.....
With the minor in mathematics?
And developers are on-call too. We have to call someone when the code sh*ts the bed at 3am
Cleaning up after code monkeys who wreck a production server is not fun.
That code monkey is the reason you have a job.
His work creates your job, not vice versa.
Remember that.
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.
Otherwise the public will think rebooting your computer three times a day is normal and acceptable.
rebooting the computer three times a day _is_ normal, on the OS that's run by the majority of "the public"... and, by and large, they _do_ accept it...
We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
the practice of leaving it the same developed in the face of a real need (non-threading usenet readers and slow discussions), perpetuated due to cluelessness (the same kind of people who hit "reply all" to a mass-forwarded email), and now, full circle, the reverse is considered clueless. yes, it does show that he just discovered the internet, and thus hasn't had time to learn all the pointless anachronistic traditional rituals (like, say, leaving the topic the same on a reply) associated with it. slashdot keeps track of threads _for_ you. you don't need to look at it and mentally say "all the messages with _this_ topic are in _that_ thread, and the other ones over here are..."
We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
The real problem is the breakdown of team work between the various admins and the developers!
This guy is venting one-sided only! Reality Check -> Developers don't know jack about SysAdmin nor DBA duties, nor the bigger picture!
I'm a SysAdmin and I've seen it all! I just cleaned 253 spyware packages off a 'developers' laptop. Developers have admin rights but they are always breaking their systems! Last month, we caught a consultant with the MS-SQL Slammer worm on his laptop. The laptop was not a company laptop but the developers personally owned laptop! That's a big time no-no to connect uncontrolled computers to the enterprise network. The consultant was fired on the spot because he brought down numerous production MS-SQL servers. All because he wouldn't play by the rules. Now we have MAC address checks before an IP address is doled out. Took months to collect all the appliances MAC addresses. (yeah they should have been patched but the worm would not have been introduced normally either).
Granted, the developers sometimes have problems, such as a non-production server going down (dev or QA) and it's used for source code control. This means they can't work, but then they report it to the help desk at 6:45pm on a Friday and the help desk cannot open a priority ticket for a non-production system. A priority ticket pages the world and kicks in emergency restoration managers and various conference calls. After this happened a couple of times, it came down to communication!
i.e. we hold daily outage meetings and weekly meetings where those responsible for various systems have to attend if their system was down. Root Cause is determined at these meetings as well as procedure refinement.
So the developers were told they needed to have a seperate source control server which they needed to purchase for their department. Then it was assigned a priority support level which they again had to pay for.
Yeah, the money is funny money, it's all budget dollars. But you can't ask the SysAdmins who pull 60 hour work weeks without extra pay and they are on call all the time to work for nothing. This money goes into keeping them trained and paying for days off after a big outage.
Frankly it goes like this:
Production Server (financial transactions) - QA Server (duplicate of ProdSrv for testing) - Dev Server (Latest wiz-bang code testing). - Source Code Control Server (some ability to run as a backup to the Dev Server)
Change control prevents any code from going into production without proper red tape paper work and lab testing. It's your ass if you rollout a big system riddled with bugs into production. The change control process may be a pain but it will save your butt.
The production servers go down and literally hundreds of users performing financial transactions can no longer do their job. Within an hour of down time, millions of dollars could be lost!
QA or Dev server goes down? After Hours? Nobody cares except for the QA developers. It will be fixed during normal business hours the next working day.
Source Control server goes down? After Hours? Well it was decided that was important because developers work long hours and under tight schedules. So therefore, these boxen are given priority as it directly impacts the development teams productivity. BUT THEY PAY FOR IT! IT'S NOT FREE!
Whole seperate lab setup with isolated network for testing. It's easy and convienant for developers to get into the lab. They just need to schedule time.
Yeah it sucks for everyone. The developers hate the red tape and the sysadmins. The sysadmins hate the developers, the engineers hate the users, the users hate the help desk. Everyone hates the consultants and the entire idea of outsourcing. So we end up shooting ourselves and IBM comes in and half the staff is let go. Part of the reason for the outsourcing is due to enterprise management being unable to get change happening fast enough! (several mergers of compan
"America was really built by poor immigrants, like my ancestors from Poland, who scratched the land for a living and asked nothing in return except the freedom to do so" Your ancestors got paid. The Chinese, Native Americans, Africans, etc did not get a penny. Big difference between immigrants getting paid very little, and free labor. Who built the whitehouse by the way?
People don't exist to serve systems, systems exist to serve people.
BS, look at history, most bosses are white males. Most tech workers are white males. Most white males over price themselves out of the market. Its funny that you'd refuse to work at mc donalds or burgerking, refuse to cut grass, refuse to do other jobs from which there are plenty of, yet you expect Indians to step aside so you can work in the tech industry.
People don't exist to serve systems, systems exist to serve people.
Having dealt with app developers who insisted on installing in C:\(appname) with no means to change the path, or using Windows Installer but not having a copy of the .msi image handy for the next user who logs on and uses their app (auto-repair), it boggles my mind that some developers, at least for Win32, can't code for security even though it's easy to do.
.msi somewhere convenient like your install directory, so restricted users can run the MSI auto-repair facility if needed (MSN Messenger does this)
1) Write settings in HKEY_CURRENT_USER
2) Store user data and documents in %USERPROFILE% or whatever "My Documents" points to
3) Install in whatever the Registry says is the Program Files folder (not always C:\ by the way, guys!)
4) Store machine-specific stuff in %ALLUSERSPROFILE%, and if that returns "Access Denied," save it in %USERPROFILE% anyway
5) If you install from the web and use MSI images, store a copy of the
I'm sure I can think of a few others. Hell, it's possible to make QUAKE (All versions!) multi-user and restricted-user-safe. If that's possible, then making your application multi-user and restricted-user-safe is possible too. And you won't be giving folks like me a headache.
Use Evolution instead of Outlook? Bewa
Great postings and comments on the plague of being "titles" such as developer, sysadmin, manager, tech, user, hacker, etc. and so on. Everything I've learned has been from other people I've communicated and worked with. What works?
Communication. Communication. Communication.What doesn't work? Well, often a lot of this computer stuff does NOT work.
Who turned off ping? Huh? Why is the Novell32 software listed as a 16 bit application and why does it lock up the laptop when I unplug the network cable. I am installing Microsoft Windows NT Server on the laptop because Windows NT Workstation is missing a few things that I want to use. Domain? What the heck is a domain? And why should I care? I use peer to peer, haven't you ever heard of that? Not everyone runs "Microsoft network" yunno? I forgot to insert that 5 1/4" floppy last night so that the automated backup will run properly. RFCs? Lots of reading... It was useful to learn that we can separate Development - Testing (Alpha) - Beta (User testing) - Training - and Production. With lots of resources we can create separate networks/machines/etc and with limited resources we can still do the same all on that old 166MHz Linux box. And going further and running applications as separate non-root users. No I don't want to run that as root. No I don't want to do development with the root account. No I don't want the root password. SysAdmin is boring. Programming is fun but it's addictive and consumes more energy that it would taken to do the thing manually in the first place. Here is how I use grep: man grep; grep attempt; man grep again; grep attempt again; hmmm better ask someone how to use this grep thing again. You want to hard code that fixed length, sure, no problem boss, I won't ask any questions about this and my other programming friend mentioned something about job security. Outsourcing, sure I do outsourcing, please wire the money to my offshore account thank you. In house, sure I do in house programming and it's usually even done in a house! So let me get this straight, you guys put in delay loops randomly scattered throughout the source code and in exchange for paying a bit extra for the "Pro" version you will actually go back and remove all of those delay loops from your code, amazing. My favourite user programming language is HTML. I love those one liners (perls of wizdumb) that you can type on the command line, they do a lot in one line and I have no idea what any of it means. I've spent months researching, documenting, prototyping, putting out surveys, having meetings, creating elaborate clever applications and decided that we need to go surfing -- everyday.
Great idea.
Just let me check that I'm not your customer, and that I don't have any shares in your firm, first.
That might have worked in the 50s and 60s; companies actually depend on their IT infrastructure these days.
Author, Shell Scripting : Expert Re
more specifically the developer the parent wrote this about!
He mentioned it three times that ping was disabled on the router. Public Registrar or not, the developer would not be able to ping the ftp server.
Can I get an eye poke?
Dog House Forum
You guys in the US need to get out of your country a bit more, just so you realize the gross misconceptions you have about other countries.
Third world countries do have unions. If anything they are a worse PITA for companies because they have far too much political power.
Third world countries normally have minimum-wage laws. I have lived in 3 different continents and visited as many as 20 countries while working, so I think I know about this.
Worker compensation is variable (if you mean to compensate for dismisal). In some countries when you are fired you are entitled to compensation. Tell me it is like that in the good ole US of A...
Regarding corruption your point is mooth. Any company with HQ in the US (and soon also in the EU) is legaly liable if they bribe people in foreign countries. Companies go to extreme lenghts to emphasize this, we IT sods have to go to training as well to make sure we get the point. You may be legally liable if a company working for you gets involved on the same practices, but here I have to conced that you have half a point since corruption is much endemic, unlike the US where we have ENRON or Europe where hte EU comission can't justify their spendings for 8 years in a row....
The US benefitted greatly from globalization, not they are suffering a mild backslash. Well, shape up and live with it. This is how things are going to go if we want healthy economic in our countries.
IANAL but write like a drunk one.
Maybe one of the bulbs has burnt out on your FDDI ring!
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Thank you for an absolutely brilliant post.
Specialists can only exist because of the foundation laid down by generalists. Sadly, corporations do not see this obvious truth and value people with only very narrow skillsets because they are able to assign a title to them.
How many individuals can completely design, implement, test, install and manage complete end to end systems spanning desktop GUI, web, database and distributed servers these days? Not many. And the specialists will continue to drive these resourceful people out of organizations due to self-interest.
However, these same companies will soon begin to wonder why projects are not elvolving at the rapid pace they did in the "old days". They will just assume that they need to hire more specialists, and the problem cycle begins again. A top-heavy organization like this cannot be salvaged.
Do not confuse the term "generalist" with the much overhyped term "architect". An architect is a person who is simply all talk and cannot do what they say. A generalist can perform all the functions of an architect and can back up what they say with action. Generalists are the people that actually get the job done.
SysAdmins and Security Admins are not the sole cause of slow development.
We have a specific role and that is to maintain the uptime and security of the production systems.
That comes at a price, developers can not just do what ever the hell they want when they want. Especially since most of them have no concept of server security. What good is their software if it is running on an owned box?!?
His statement about virus software is totally out of line. Unless his machine matches this description: has no contact with other machines on the netwk, can not get out to the public net, and can not receive e-mail; then and only then can he run his system without virus protection software.
That is just pure stupidity. What's worse, running slow, or having a virus blow away his machine to the point where he loses all of his data/
The one point I will concede that developers should have at the min power user rights if not local admin rights. But it comes with a stipulation, you break it, you fix it. And they run their machines in a dmz/vlan aka A DEVELOPMENT LAB>>>.
We don't tell *you* how to code, don't tell us how to do secure out networks.
/\Long live the BOFH!/\
We're all born clueless, but the years have not improved your condition. I have no doubt that many old buildings in the original colonies were built using slave labor. That is a small piece of the country, and the number of slaves was a small percentage of the population.
The Chinese were not enslaved. They may have been paid very little, but as you conveniently point out, that's not slavery. The Native Americans got a raw deal, but they were not enslaved, and they still get payments from the government.
My ancestors did not get paid. They lived by farming and traded for the things they could not make. Don't try to change your argument when you can't support it. The country was built by poor homesteaders.
Your namesake was a coward who committed suicide. Do we dare hope for a repeat performance?
"The Chinese were not enslaved. " Yes actually they were when they first came here. As were Native Americans, the difference is Asians and Native Americans did not make good slaves.
People don't exist to serve systems, systems exist to serve people.
Indentured servitude is not the same thing as slavery. And attempting to enslave someone and failing is not the same thing as enslaving someone - obviously.
So when are you and Eva going to take the plunge? Will it be gruesome? Will you avoid the coward's poison and take it like a man this time? Do you have the courage to put the business end of a Luger in your mouth and pull the trigger or perhaps fall on a ceremonial sword?
The article seems to imply that all this administration is a waste of time that interferes with work, but when your network is at 99% utilization because of (say) 20 Slammer-infected machines that the developer was too lazy to patch, while all centrally administrated machines had the patch on months ago, then who is wasting the company's time.
Like any other process, centralized administration does take some effort to prevent it becoming a bureaucracy. But, if properly managed (and it is at some sites and companies) it allows the developers to concentrate on *developing*, instead of all the effort taken to make their servers safe, and keep them safe.
Any relatively large organization learns some painful lessons the hard way, and puts policies in place to prevent a recurrence of these lessons. Don't just complain about having to run an AV and firewall, think about why they're there, and what could happen if they're not. If you think the process *really* sucks, then offer suggestions on improving it.
Generally, admins have a job to do. They don't have time to intentionally sabotage your work, because they're too busy repairing the unintentional sabotage the idiot across the hall just did to his own work. So before you blast your admin, walk a mile or two in his shoes (or Birkenstocks).
university of phoenix?
The only reason it was easy to enslave Africans was because Africans did not speak a common language or have a common culture. Unlike China, the cultures between tribes in Africa is vastly different and some tribes in Africa were glad to see their competition taken away into slavery and actually helped. This is why slavery worked for a couple hundred years. If you cant read and cant communicate its going to be difficult to organize a rebellion.
People don't exist to serve systems, systems exist to serve people.
OK, so you map port 80 to 8000, but how do you convince Apache not to redirect its /-less directory requests to http://my.example.com:8000/path/to/directory/ ? Apache's configuration has many arbitrary limitations in that area and you have to invoke some module from hell to get it right. Do you just enable mod_rewrite and accept the risks? I'm not willing to do that. What else, hack mod_dir to leave off its port number, so my fellow sysadmin no longer knows how to upgrade Apache?
Generally speaking there is always a tradeoff: tightening security on one point is going to complicate the mechanisms of operation, which is not only more work for all concerned, but also brings new risks to security and reliability.
All I have to say is that their are checks and balances in everything. Network administrators are there to do just that. Keep your network running in a smooth efficient manner. That is the way I run ours anyways. Sometimes I do resist change but not to make life difficult. Sometimes there seems a unknown purpose for resistsnce but if some little code change or database table decides to make the entire network take a crap the developers are usually the first to point the finger and back away stating "I'm only the developer... He should have known this would happen" The article while amusing to some just goes to show why Network Administrators exist.
As a vetran network admin I have to totally disagree with you. I am therefore going to lock out your account, restrict your rights to your files and re-direct your e-mail.
Seriously though.... As a vetran network admin I'd have to say I've seen a lot of this myself. You ask the average guy looking for IT work what he thinks his job is and you hear things like manage accounts or maintain servers. Very seldom does the mention of another human come into it.
It's the guy that says: help the end users do their jobs better that I give the job to.
Finding a balance between security and flexibility is something that only comes with experience.
The breakdown of computing jobs into more and more specialized professions is leading all of us into a devolutionary trap. One person doesn't know how to do everything anymore, everybody knows how to do one thing really well. The industry changes so fast that something you specialize in now may not exist in a year's time, and then where will you be? In the animal kingdom, creatures that specialize into specific roles must band together or they perish. Evolution doesn't encourage specialization.
That has nothing to do with anything remotely related to your argument, and why are you still alive?
It is way past time for you to collect your Darwin Award. Your trollish traits cry out to be removed from the gene pool. Do it. It will be a relief to you (and certainly to the rest of us). If you don't have a bunker, perhaps your parents' basement will do.
"However, there are a large number of DBAs who don't understand databases. Their position of authority comes only from them holding onto the database permissions."
Oh man, does this statement hit home. I don't agree that all role fragmentation has been bad, however. The above statement may resonate truth, but it wasn't caused by role fragmentation per se. It was caused by ineffective business process and ineffective people in IT management.