Fog Creek Software
Discussion Board




Programming support

A main problem I find in programmer-heavy organizations is that support people are treated like subordinates.  However, they (sysadminning, testing) contribute heavily to the success of a company. 

But at a company in SF I worked at, a manager one day joked to a very professional admin, "That's why you're just a sysadmin and not a programmer."  I had to cringe and look down, even though it was a joke.

In Peopleware, I read with great interest about IBM's Black Team, a bunch of testers who took extreme pleasure in destroying your program.  Hmm..  The testers at my company are treated like necessary annoyances.  I want the Black Team.  The difference here is that the testers here have no real ground to stand up.

Often, programmers complain when they're working for a non-software company.  No doubt, non-programmers often feel the same way at programmer-heavy companies.  Does anyone have any knowledge about how companies accomodate these support people, and give them an elite feeling?

Peter Wagner
Sunday, January 13, 2002

I started professionally in as much a support role as a developer.  Support people, good ones, can develop, developers even great ones (perhaps especially great ones), have problems doing that.

Simon Lucy
Sunday, January 13, 2002

I think that at any company you'll find that the people who are central to the business are treated better -- some people are more equal than others.

A software company can produce software without programmers, but not without testers. Likewise, Hasbro Toys can continue to produce toys without programmers, but not without toy designers.

But for testers, there is hope I think. Just make testers equal in power to developers -- test managers and dev managers should report to the same boss and should be peers.

The job of Test is to sign off that the product is of good enough quality to ship (where -good enough- is defined differently depending on whether you're developing CityDesk or embedded CAT scan software). If Test doesn't sign off then the product doesn't ship. This gives Test at least 2 major sources of power:

1) Test can deny the addition of new features or cut existing features by claiming that they have no time to test them and therefore can't sign off on them.
2) Test can enter lots of bugs into the bug database (you do have one, don't you :) and claim the product isn't ready because of the quantity of bugs.

Both of these are reasonably supportable claims that are easily justitifed to the uber-manager. Dev has no choice but to react.

A system like this at least gives the _opportunity_ for testers to gain respect. With the system in place it's then up to testers to prove themselves.

Malcolm
Sunday, January 13, 2002

I see this as part of a long standing conflict between producers and inspectors.

Producers say " these inspectors are a waste of money; just fire them and hire a few more producers like us and things will improve".

Inspectors say " we inspectors are vital; with the results of the inspection, the producers know how to produce better code".

In times of trial when management seeks to cut costs by laying off people, they may have to choose between laying off the developers who produce the code and the developers who inspect the code.  In fact, an easy compromise is just to stop doing inspections.

Keith Paton
Sunday, January 13, 2002

The reason why sometimes QA professionals are looked down is that they do not affect the bottom line.  That is their efforts do not directly produce revenue.  Also most managers do not fully understand the need or contributions of a good QA team.  Sad but I have worked in a few places where their is no QA and when asked the manager would remark to the fact that if we were so good then why do we need people testing the software.

Woody
Sunday, January 13, 2002

I think it depends on how the person thumbing their nose at others sees their job. I'm a network manager rather than a programmer btw, though I can program. to an extent

I don't think that means I can turn out code to the standard you pros can, but there is no way a real good network/systems manager can claim to be all that at their job without at least having a command of basic scripting.

I know plenty of programmers who can set up a couple of machines on a network and get them to talk to one another, but that isn't quite the same as what I do. But I don't see how someone could claim to be a really good programmer without knowledge of how the platform they are working on behaves.

The problem arises when the network manager who can script rises to a position of authority and thinks that scripting means they understand professional programming, or the programmer rises in the same way and thinks that getting two machines to ping one another means they know it all about networking.

Smart people know they can do a lot of stuff. REALLY smart people know what they can't do, as well. We've all got limits and we all need a team around us; really smart people know that and realise that having a different skillset from yours doesn't automatically make the other person more or less valuable than you.

Robert Moir
Sunday, January 13, 2002

Everybody needs everybody else, of that theres no doubt, any good programmer can work out the sys admin stuff if they have the time and opportunity. The opposite is true too. Given that the time and opportunity does not exist for both groups, which one can be done without? The difference is that the programmer produces 'product' and without that everybody else is redundant. So with 'product' the desired goal can be achieved, no matter how fault ridden it may or may not be. Without the 'product' nothing can happen.

So the programmer is more necessary.

Tony
Monday, January 14, 2002

Bollocks. That's like saying that the engine is more necessary to moving the car down the road than the wheels are. Both are necessary; neither is sufficient.

Mike Gunderloy
Monday, January 14, 2002

Reading my question, it seems like the obvious answer is, "Read Peopleware, and think."

What I wanted to get at though is that support/infrastructure positions often have special features that make them very easy to mismanage.

For example, take sysadminning.  It is sometimes said that the stability of their systems goes up with the amount of time a day they spend playing Quake.  That is because they tend to work a fury building and documenting a system, and then just spend their time waiting for something bad to happen.  So the focus perhaps is best on "preventative medicine."

Many businesses mismanage admins, holding them to the same puritanical demand for hours worked heads down.

I ask this here instead of say, "Roderick on Systems," because programmers want specific things from admins/others, but are not necessarily very competent in getting it from them.

Peter Wagner
Monday, January 14, 2002

RobOnServers..

My site *does* need a new name. LoL.

In my experience, I think most friction between programmers and sysadmins comes in where we don't understand one another's needs.

If you don't think the sysadmin understands why you want something then explain it. Get them to explain why they have a problem with something you asked for by listening and trying to work out compromises you can both accept. Once the sysadmin understands the coders really do need that level of access and are not asking for the sake of it, and once the programmers understand that the sysadmins are refusing to hand out root, or allow beta software to be installed,  on a mission critical box willy-nilly because they have a genuine concern and not because they are power mad, everyone's day gets easier.

The attitude thing is a factor though, I've had one coder where I work ask me why I don't code, and asserting that he gave up fiddling with his computer settings years ago, as if he thinks I do that all day!

Robert Moir
Monday, January 14, 2002

To Mike above.

Bollocks? What on earth are they?

I see your point, but I'd rather have an engine and need to put the wheels on, than have the wheels and need to build an engine.

Using your analogy, which is the hardest to build, the frame holding the wheels, or an internal combustion engine?

Tony
Monday, January 14, 2002

Sure, I can agree with that. I think it's just the notion of "more necessary" that set me off. "Necessary" strikes me as a binary, not a continuum. Perhaps "scarcer" or "more valuable" would be a more precise way to identify programming skills.

Though I'm not entirely convinced that good developers are in fact scarcer or more valuable that good sysadmins or good testers.

Mike Gunderloy
Monday, January 14, 2002

I dont think that anybody is more valuable than anybody else, one can plausably exist without the other, certainly not if you want to do a great job, but it can be done.

In a perfect world, I agree, both are needed.

Its funny, as a developer, I've had the odd run in with the sysadmin area (had one yesterday in fact), basically I'm working with the business to develop a solution for a problem. Eventually the business and the software pull together to build a viable solution, after  months of effort.

We are ready to demonstrate the software to the management group.

Then what happens? The sysadmin area revoke the user access to a network folder that was set up, merely as one of the developers had not signed a confidentiality agreement. The database contained test data, i.e nothing real.

So we put in an phone call asking for temporary access and are told that this will take two days.

Some people are merely list tickers, and my experience is that a lot of them work in sysadmin.

End result, someone from senior management rings up and tells tham to do it NOW, and it gets done immediately.

Sucks.

Tony
Tuesday, January 15, 2002

"Then what happens? The sysadmin area revoke the user access to a network folder that was set up, merely as one of the developers had not signed a confidentiality agreement. The database contained test data, i.e nothing real."

Yeah but I've worked in plenty of places where we're told that we (sysadmins) are responsible for securing the network and we'll "merely" get fired if we don't take rules like that confidentiality agreement seriously.

If your development team and your systems administration teams are in conflict, you have a management issue because they have probably been set conflicting goals. That isn't your fault or theirs. Go speak to the PHBs.

Robert Moir
Tuesday, January 15, 2002

There's another source of tension between developers and sysadmin. The developers depend on the sysadmin and expect perfection from them.

When I flip a light switch, I expect the light to turn on. Similarly, when I'm at the office as a developer, I expect that all computers, networks, email, databases, etc. will always be working perfectly. My schedules presuppose a perfect IS environment, and I'm idle if the IS infractstructure isn't fully functional.

Intellectually, it's clear that demanding perfection from IS isn't reasonable. Still, all developers, including myself, become incredibly frustrated if IS issues hold up their work in any way.

The developers are totally dependent upon IS. At the same time, many developers can't help feeling, often unfairly, that any IS issues that arise are caused by a lack of intelligence, competence, or dedication on the part of the IS personnel.

Jared Levy
Saturday, January 19, 2002

"When I flip a light switch, I expect the light to turn on. Similarly, when I'm at the office as a developer, I expect that all computers, networks, email, databases, etc. will always be working perfectly. My schedules presuppose a perfect IS environment, and I'm idle if the IS infractstructure isn't fully functional."

Fair comment, but you need to consider some things. Firstly, your schedules may need some work in order to become more realistic. You can't legislate for hardware failiures no matter how good your support team are. Presumably your schedules would also be in trouble if you fell ill and had to take time off work?

"The developers are totally dependent upon IS. At the same time, many developers can't help feeling, often unfairly, that any IS issues that arise are caused by a lack of intelligence, competence, or dedication on the part of the IS personnel. "

I'm glad you note this is often unfair ;-)
I can recount many stories of developers who managed to break equipment that worked perfectly until they got ahold of it! Whose fault would that be?

I remember one incident with a developer back when I was on a helpdesk, who screamed at me that his machine was broke, that he had schedules dammit, and was going to have my job, because his machine refused to start, giving the error "non system disk". I asked him if he had a disk in the drive, and he replied "Don't insult my intelligence, I AM a programmer you know, I know about those things, now get over here and fix this [bleep] thing". I went over there, removed a disk from his drive 1 second after arriving, and handed it to him.

As I've said before, the interaction, the frustration, and the appearance of a lack of understanding and intelligence is a two way thing. Teamwork is what counts.

Robert Moir
Sunday, January 20, 2002

*  Recent Topics

*  Fog Creek Home