Outsourcing

Developers, how often do you do systems administration work?

Justin James says that up to 25 percent of his development work per week is systems administration. Take this quick poll to let us know how frequently you do systems administration.

Some developers end up doing a substantial amount of systems administration work. For instance, it often takes a lot of effort to get a development environment set up. In other cases, developers need to work closely with systems administrators (or even take over) when deployments are done.

In many of my programming jobs, systems administration could easily consume 8 - 10 hours a week of my time. I wonder how much systems administration the average programmer actually does these days. Take this quick poll to let us know.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

About

Justin James is the Lead Architect for Conigent.

31 comments
mikifinaz1
mikifinaz1

You don't have time to keep up the programming, and end up having extra duties. Once you have done it, add it to your resume and then play dumb. Most companies require 24/7 IT and programming can be done 9 to 5 most of the time.

mattohare
mattohare

I do all my sysadmin. In most jobs where I did the database development, I did a good share of the server admin work as well. It wasn't a large shop, and it gave me a chance to make sure no part of the process impeded another. (Much like a farmer would and should check the fence around his land to ensure it's all there.) All very well to have some division of responsibilities, but don't divide so much that gaps form.

TexasJetter
TexasJetter

Actually I am an Systems Admin that does programming. So it might be interesting to see how much programming time a typical Systems Admin does . . .

Justin James
Justin James

It used to be that sys admins doing programming was mandatory. Windows Server eliminated that for the most part (although a small percentage of admins used VB Script frequently; I still use batch files out of habit), but with PowerShell, programming for sys admins is becoming fashionable again. J.Ja

mattohare
mattohare

They seemed to think they could have the same 'IT Manager' handle all their sysadmin, web development and programming needs. I was the interim sysadmin. What an 'adventure' it was.

kovachevg
kovachevg

Java EE dev environments can be a killer. When I started at my current position 11 months ago, setting up an environment would take between 2 and 4 days. Fortunately management took that to heart and with the help of some of the more experienced developers I created automated ant scripts that take care of almost everything: pulling the latest build, deploying PL/SQL code to your personal schema, pulling the latest source code, and recompiling the project. Now the time for system administration is down to 30 minutes, and this is usually the time necessary to run the scripts, fix minor errors that someone caused though incomplete commits, and restarting the Web Logic app server. Automation is at very different levels of maturity across companies. Any serious IT manager should have several team members who are completely focused on automation. The ROI is massive :).

Justin James
Justin James

In 2001, I took a Java development position, with Oracle on the back end. One of the other developers needed to spend a day setting up my environment, and even then, I was finding wrinkles for months. To make matters worse, it was Apache/Tomcat on Windows on my desktop, but iPlanet on Solaris on the actualy servers, and there would be subtle differences all the time in some very frustrating way! In my last job, I needed to do a lot of Web Logic administration... very frustrating, and very poorly documented. I don't know what is wrong with the J2EE world, but they relly need to get these things to be easier! J.Ja

Osiyo53
Osiyo53

In the kind of work I do, it is sometimes necessary to put on my "administrator" hat. Mostly because we'll develop and install apps that then do not work as expected, for one reason or another. Sometimes our fault, sometimes the fault of the customer owned system its installed upon or the network it connects with. When its the later case, typically the customer's IT people always claim that it can not possibly be THEIR fault. To be expected, it's the predominant response and claim I run into. I'm used to it. Will try at first to work WITH them. But if that's not possible I'll just jump in and troubleshoot their system, identify the problem, log my proof, fix it if allowed or shove proof under nose of the IT folks and tell them to fix it and how it needs fixing. Not knocking the IT folks. They have their own troubles and work to do. To them, I'm an outsider coming in who installs stuff that may just make more work for them. But it is what it is, THEIR bosses hired me to install the stuff, so they've got to live with it and any unique requirements it has.

rpmcaninch
rpmcaninch

This is sadly true for me as well. As soon as the company that I work for decided that it isn't their "core competency" to manage and develop their own computers and programs, it was all farmed out to other vendors. The problem is that the responsibilities are so fragmented that each company only sees a small part of the pie. When we handled it in house, we could usually just fix it and move on. This usually took less than a couple of hours at the most. Now one has to sit in conference calls for hours at a time with a group of five to eight managers to try and get the right person the needed information to perform the fix. It's a mess.

Tony Hopkinson
Tony Hopkinson

:( MAO

dbwriter
dbwriter

Our corporate logon script will take at least twenty minutes, up to 45 minutes on older machines that are used by the factory people. No one WANTS to shut down because of the time it takes to restart. And as the person who has to do the trouble-shooting, I spend way too much time just waiting for a reboot!

dbwriter
dbwriter

If we keep letting the "bosses" continue their selfish ways, we will never get out of this horrible morass of bad thinking. Come on people! We know things are wrong but we are so afraid to loose our job that we will not act! We are more numerous than they!

Tony Hopkinson
Tony Hopkinson

It might actually be better to take the efficiency hit, in return for the lower electricity bill. You can pretty much guarantee it hasn't been investigated. After all if the idea turned out to be a lemon, no bonus, no promotion, nothing to talk about while losing at golf, major downer career wise.... It's makes you want to cry we are continually told to look big picture, align ourselves and all that other guff, yet if you present a complete utter waste of resources as a cost saving... My question would be why would you pay a manager to put stickers on monitors, if that's all they have to do, sack them and give some gowk dragged in off the street a few quid to do it.

Tony Hopkinson
Tony Hopkinson

to irony and sarcasm mate. It's not even cheaper in the accounting bottom line, if you look bast this fiscal report, but they seem to be intellectually incapable of managing to do that. Mr Magoo is in charge

Justin James
Justin James

If you ever want an explanation of the many "penny wise, pound foolish" business decisions, just ask yourself how the decision maker's bonus is calculated. I guarantee you that "productivity" and "frustration" and "employee retention" are not in the formula. Instead, you see things like "employee cost", "revenue per employee", and so on. J.Ja

rpmcaninch
rpmcaninch

It allows one department to claim a savings without the also explaining why it is causing another department to absorb higher costs. For example: We have a manager that goes around placing stickers on LCD monitors and computers if they are left on at night. He has claimed a big savings on electricity for last year. It costs about 85 cents a year to run a modern LCD in standby. A computer is more, but lets say it costs a whole quarter to run all night. In the morning, an engineer has to wait five minutes or more for the PC to power up. At $100 per hour, that's a $9.95 loss. In addition, instead of running a virus scan during the day that interrupts work for about twenty minutes (a $40 loss,) we could run it at night, if we could spend the quarter to leave the PCs running. High level business managers are so engrossed in saving a penny that they have gone to extremes to gather data to show a savings somewhere. They forget that the business works together as a whole, not a bunch of isolated pieces. Since the Harvard School of Business is the defacto standard for business management, I'd say that they dropped the ball, and the other business schools failed to notice.

Osiyo53
Osiyo53

"Cheaper in the accounting bottom line." This says it all. In some cases yah have to remember that the manager or exec making the decisions is more concerned about TODAY, as versus tomorrow or some period down the road. The decision maker looks at immediate results of a plan, if it makes him or her look good THIS TIME, today, and will reap suitable rewards for that person such as a bonus or promotion or whatever ... go with it. Six months or a year or two down the line? Decision maker by that time has reaped the immediate rewards, will worry about the future when it comes. Or not worry about it at all if he or she has been promoted to new position or otherwise moved on ... because now its somebody else's problem. It's just a common practice these days. Farm out various functions, get folks off the payroll. If a businessman could figure out how to do business with ZERO employees on the accounting books, zero investment in capital goods and equipment, etc he or she would go for it.

dbwriter
dbwriter

Cheaper in the accounting bottom line. But what about lost productivity? Strain on the Users? Strain on IT to try to resolve the problem without trying to call in the so called experts? Loss of time to devote to other projects that would be more beneficial and cost-effective in the long run but have to be put on the back-burner because we are wasting our time on putting out fires rather than on predictive maintenance?

ByteBin-20472379147970077837000261110898
ByteBin-20472379147970077837000261110898

I work for a web hosting company and you could say I do a little of everything from admin for the LAMP server, script and other programming, web development, documentation, site/server maintenance, consultation, etc. It's a fun mix and always something neat to work on, which is why I love my job. It doesn't get boring, that's for sure.

dbwriter
dbwriter

I love the variety of dealing with all things with a "plug" attached. However, corporate has been pigeon-holing everyone nationwide so that a person can only do one task - at all. Has anyone else been the "victim" of corporate "streamlining"? Where nothing gets done because you don't know what the heckm is going on unless you have a help-desk ticket?

Slayer_
Slayer_

I am a developer, but, except for setting up hardware and crap, I have to do most of it. I actually got sick of our server going down and set up this old beater machine next to me to have week old duplicates of our primary databases, just so that our development environments don't keep going down. On every install I pretty much do everything, from the files, to the database, to the conversions and scripts, to the actual system itself. Yesterday I had to fix a ladies machine that was completely wacked, I event ried to defrag it and 99% of the bar showed blue, and yet it apperently had 70% free space.... I scheduled a full chkdsk for her and told her to restart her computer when she goes for lunch. Not complicated, but the fact that I do it at all.... I've also had to numerous times, re-route network cables on our servers.

jslarochelle
jslarochelle

...based acquisition "drivers". In the old days we were using interrupt/DMA based drivers for our instruments. This often required debugging to fix interrupt number or DMA channel conflicts. These days we use TCP/IP based protocols between our instruments and client applications. This is much easier to manage. The Java socket library also helps because it is very good compared to the third party libraries that we used in the "old days". The only problem with this is the poor quality of the Windows TCP/IP stack and the sometimes chaotic nature of the security patches applied to it. This has been the cause of most of my recent Sherlock Holmes style involvement in fixing installation problems. JS

Mark Miller
Mark Miller

In most of the IT jobs I've held system administration is a significant part of the job. In every case I was allowed to learn these tasks on the job. In one place where I worked for 4 years my system administration responsibilities increased the longer I stayed there. We eventually got a Windows administrator to handle Windows servers, but I was the main Unix guy. I and a system architect there were the only ones with Unix skills. He was too busy doing design and writing documentation, so it was left to me. It got to the point that I was practically the in-house DBA, for a time. I also managed backing up the Unix system to tape on a regular basis. We went through a change of management while I was there and it was difficult to get across to them that it was impossible for me to spend 8 hours a day just on development. I had to spend some time doing administration, because there was no one else to do it. Through my career I've had to install operating systems, RDBMS systems, schedule tasks to run automatically, do some network configuration, and of course install software. In one job I held I even replaced a motherboard on my work PC, and had to reconfigure/reinstall the OS afterwards. The main system administration task I had to deal with consistently was doing database management. I didn't particularly like it, but I can see how necessary it was for the work I was doing. If you want your software to work with the database you need some level of control over it. Though I've heard in some corporate environments they are so anal they only allow DBAs to configure the databases. Developers are not allowed access. To date I haven't had to work in an environment like that, and I don't think I'd like it. The stories I heard about DBA control said that developers had to submit every single query to the DBA for approval. I can imagine that would slow me down quite a bit in my work. I imagine now most places have an architect/DBA design stored procedures for developers to call to accomplish their tasks (I wrote quite a few of those, too). When I got into web apps. as a lone contractor I had to install them manually and test the install. The hairiest part of the job was updating the database when I'd update the app. The most uncomfortable system administration I've had to do was configuring DCOM so a web app. I wrote could start up Excel on its web server, so it could extract data from, and create, Excel worksheets. It felt like a hack (and it was). I've liked installing software that I use (though I could do without installing OSes), because I've felt like I have the control I need to configure the software that would work best for doing my job. The extent I've had to do this varies. In one of my last IT jobs they had an IT department that did hardware and OS installation for me, which was nice.

dheller
dheller

I started as a programmer long ago when the computer filled the room. I found myself doing what was necessary to keep things running, and that led to years of system management. I eventually took a job that promised me a chance to do more real programming, not just automating system management tasks. But the system management came first, so I could never accurately estimate how long a programming project would take. Most recently, at BCF, I had a programming position with no system or network management responsibilities. They have a great organization, with separate groups for operations, systems, networking, data base administration, quality assurance, user support, project management, and software development/maintenance/troubleshooting. (I would have added a separate software maintenance and troubleshooting group). The lack of worries about anything but software design and implementation sure improved my own ability to plan my daily work on the different projects assigned to me and provide more accurate answers to the request for a completion date. Having all of those services inside the company meant that we were talking to other groups to acquire resources for our projects in development and when ready for rollout to production. When database management was moved outside the company, their lack of knowledge of company jargon and independence from almost anyone else required a lot of effort to make work.

Retired_USAF
Retired_USAF

PREVIOUS POST COMMENT: Though I've heard in some corporate environments they are so anal they only allow DBAs to configure the databases. ===================== Being a DBA, this is the only way to go. Developers, and System Admins, don?t have the ?nuts and bolts? knowledge of database administration to set things up properly, know how to quickly get out of situations, etc. Additionally, since the DBA(s) are responsible for the databases so they should be the only once creating, configuring, etc them. There was a time before I got to one job, that a developer was ?acting? like a DBA, and created a table. However, the developer used wrong parameters, and the last 500MB of a file could be written to, but not read from. Well, it took me as a DBA to resolve the issue. Once completed, the developer said, ?I didn?t know that was possible?. I asked him (and other developers) nut and bolt questions about the databases (meaning setting them up, administrating them, etc), and they could only answer about 5% of the question. Each question I asked, I showed them in the manual about it, and also hands on. When I left one job, and then went back to visit, the developers had set up a job that ran 36 hours (2160 min) -42 hours (2520 min). Well, armed with my DBA knowledge, a few simple commands reduced the processing time down to about 30 minutes (1.2-1.4% of what it was). They had similar jobs that were greatly improved, because of the information I gave them. The commands, although documented, are only well known by DBAs. There is more to database administration than creating table and creating indexes. Heck, none of the developers that I talked to could even create a partitioned table or index, and that is one of the important skills for a DBA. ********************************* Now, don?t get me wrong, I?m not slamming developers, or sysadmins. ********************************* I as a DBA, and I haven?t programmed in COBOL in 14 years, so I couldn?t do a developer?s job as efficiently as one that has been doing it for years and years. All I?m saying is that for each job, you need the ?nuts and bolts? knowledge to be effective, and the ?nuts and bolts? knowledge of one job can?t easily translate to the ?nuts and bolts? knowledge of another.

techrepublic@
techrepublic@

... for both servers and desktops. Part of the administrative work is directly related to my development but the majority of it is "pure" administrative work. Since most of my development targets the server room, administrative capabilities are a good thing to have in the tool belt.

dbwriter
dbwriter

I agree. I spend so much time just keeping everyone working. The higher-ups don't understand and don't want to hear it. They just want their projects done. There is no budget to hire an admin, so I do the best I can.

Tony Hopkinson
Tony Hopkinson

I did 14 years with three hats on though (support, admin and development), so in my current wholly developer role I don't miss admin basics. Which all too many developers do....

Mark Miller
Mark Miller

From the beginning of my career in IT I was doing customer support. At first it was just the typical service level stuff, helping diagnose installation problems. Later it got to the point that I was remotely assisting other administrators with our software, which eventually morphed into me doing remote administration with no client administrator involved (though not in every case). With the kind of work I was doing I got pretty involved with the client's staff and systems. This was actually okay. I liked the customer contact aspect of the job as much as the technical, because part of what was fulfilling for me was seeing how what I had written was appreciated by those who used it, though I much preferred hearing from the end users.

Tony Hopkinson
Tony Hopkinson

and administrating what I was developing, I didn't make things harder on the other side to save a few lines of code in validation, error reporting and such.

Editor's Picks