The Rise and Rise of IT Administrators 686
maffstephens writes "Have you noticed how difficult it's become to develop software? Not because software is more complex, but because there seems to be an army of administrators standing in your way - sys admins, network admins, database admins, runtime admins - the list is endless. They should be there to help us, to make our lives easier, but the reality is often very different. This thought-provoking article from Software Reality is all about the emerging culture of spiteful, dog-in-the-manger prevention amongst corporate IT administrators. Software development has become so inefficient as a result, it's no wonder so many companies are outsourcing."
Excuse me? (Score:5, Informative)
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.
IT Differences (Score:5, Informative)
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.
Re:In all areas (Score:3, Informative)
Re:Outsiders can see the flaws better, so outsourc (Score:4, Informative)
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.
Programmer centric (Score:3, Informative)
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.)
Admins do the work Developers Don't Want To. (Score:3, Informative)
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
Re:We need more planning and less coding. (Score:3, Informative)
I don't think anyone is suggesting that developers should have root on production machines. But on their own development boxes or on test machines?
Admins, Users, Developers, and CxOs (Score:2, Informative)
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.. .)
Re:We need more planning and less coding. (Score:5, Informative)
If the app isnt running as root, you dont need root permission to trace system calls.
Unless your OS sucks or something.
Re:We need more planning and less coding. (Score:3, Informative)
This is why there is sudo.
kashani