• Subject: Re: monitoring contract programmers
  • From: DAsmussen@xxxxxxx
  • Date: Wed, 29 Nov 2000 00:29:16 EST


In a message dated 11/28/00 5:51:23 PM Eastern Standard Time, 
jimlangston@conexfreight.com writes:

> How do you know that programmers sitting in your office at a computer
>  are working and not goofing off?  Maybe instead of programming they
>  are posting messages to the midrange.com mailing list...ooops <g>

I'll answer that.  If you have five or more programmers and direct Internet 
access, at least one of those programmers is goofing off at any given time -- 
and _NONE_ of them will be your "contractors" if you hired a decent version 
of the latter to begin with.  Posting messages here, IMO, is a _VALID_ 
work-related activity.

>  Seriously, though.  If you read the regulations on overtime pay, you
>  will see that there are two exceptions to who gets overtime pay.  One
>  being managers, the other being technical professionals, such as 
>  engineers and programmers.  I tried to figure out how they came up
>  with their reasoning, and I think we've answered that question in
>  our discussions here, is programming an art or a science?  According
>  to the government, it would seem, it is more of an art.  Where the 
>  time to do anything is dependent on the artist (programmer).  Since
>  some programmers may take longer to do the same thing, the company
>  shouldn't be responsible for this, so they (the company) doesn't have
>  to pay overtime for the programmers extended time needed to do it
>  (hey, this is how I interpret it, any other interpretations?).

There are _far_ more exceptions than these -- accountants, customer service 
reps, marketing folks -- pretty much anyone that doesn't produce a tangible 
product that you can hold in your hand, but routinely works overtime.  
Collusion between the government and big business?  Perhaps.  But determining 
productivity is the responsibility of the employer, not the government.  
Slower programmers should be DEMOTED TO A LOWER LEVEL or left at the same 

>  Which brings us back down to the same problem we've been discussing,
>  how do you track a programmers productivity?  Lines of code?  Hours
>  spent in front of a tube?  What about the programmer who spends half
>  a day researching something and then finishes it the rest of the day.
>  Then you have another programmer who doesn't do any research at all,
>  spends all day doing it, and takes twice as much code.  Who was more
>  productive?  Personally, I would say the one who did the research and
>  did it in half the code.  I'll bet you dollars to donuts that his/her
>  code is going to be a lot more maintainable.

An entity _ABSOLUTELY CANNOT_ measure the productivity of programmers 
systematically.  I'll accept any refute of the previous statement from anyone 
that can measure absolutely the work done on the AS/400 vs. the work done 
designing via a PC program on the network vs. work done via a PC program at 
home because the network connection is too slow vs. work done on paper.

I've worked for several companies that measured productivity quite well via 
weekly reports and _GOOD_ job estimation.  Said weekly reports _MUST_ contain 
a section for reporting time spent "off project" or countering unforeseen 
difficulties, and said _GOOD_ job estimation _MUST_ include a method by which 
the developer can say "You want me to do _THIS_ in X time?  You're absolutely 

Bravo on the research point.

>  But now you do have a problem.  How do you know if a programmer at home
>  is working on the problem, or goofing off?  Maybe he hasn't touched the
>  system for 4 hours, but how do you know he's not doing research?  Or
>  reading newsgroups and mailing lists, like this one, for solutions 
>  (and no, I do not consider this mailing list "goofing off".  I consider
>  this very excellent research and on going training).

You cannot know if they're "goofing off".  You have to trust someone at some 
point.  If you do not trust them and are adequately monitoring productivity 
then either a)  You need to find another employee or b) The employee in 
question needs to find another job.

>  You basically are going to have to do it the exact same way you do it
>  now.  Give them a project and a time line.  How close to the timeline
>  do they come?  If they are coming in at the timeline about the way they
>  are now, they're not goofing off.  If it suddenly takes them twice or
>  three times as long to do anything, bring them back into the office.

Bravo again, as long as that timeline allows for deviations such as 
supporting live systems, unforeseen technical difficulties, downtime 
problems, etc.  Granted, some people are just not cut out for work at home 
and do not possess the personal integrity to do so.  Others need delineation. 
 I have a friend that works from home sometimes as do I -- he had to rent 
office space because he could not draw that line between his office area and 
his home space that children and spouses are not to invade during work hours.


>  Allowing people to work at home is a big step, and a totally different
>  approach needs to be taken in managing them.  No longer can you think
>  that cause they've been here 8 hours at the computer that they put in
>  a full days work (heck, half the time that's not even right with someone
>  at the office).  A lot more individual managing needs to be done.  I
>  have read a lot of articles on the subject, and I would suggest you 
>  look some up.

Other than it being a big step, I totally disagree with this statement.  The 
_BIG_ step is in managing connectivity, how much hardware to provide (if 
any), and how to provide support for systems that do not necessarily conform 
to the corporate standard.  IMO, providing preloaded hardware is _FAR_ easier 
than maintaining everyone's' home computer.  If you're managing properly 
_NOW_, managing telecommuters should be no more difficult, IMO...


Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"It is said that power corrupts, but it's actually more true that power 
attracts the corruptible.  The sane are usually attracted by things other 
than power." -- David Brine
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].