|P is for Practical|
Re: On programmer schedules and productivityby Sherlock (Deacon)
|on May 11, 2001 at 02:58 UTC||Need Help??|
I can't agree with you more. Being in such a business, I really don't think you can respectably measure an employee's productiveness by how long they're sitting in their seat at work. There have been a number of nodes on Perlmonks that show that many developers take their work with them wherever they go - often, they leave the office simply because they can do better work outside of their cubicle. Check out Maintaining one's focus while working (alpha/beta/delta brain waves) or Programmer's Frustration. These nodes dove right into the fact that developers need some time out of their chairs.
Personally, I find that I sometimes get very little done at work because I feel a lot of pressure or I'm just wishing I could be anywhere but in my chair. For a knowledge-based industry, if you can't stay focused, you're really not doing any good. That's why programmers have learned "when to say when." Most of us know when we've had enough for the day.
Granted, I have no problem with putting in long hours when need be and it doesn't sound like your employees do either. If you can count on them to get the job done, I don't really see what the problem is. I think you might want to take a different approach when dealing with your supervisors, though - get them to focus on the finished products produced by your team. If your team is doing as well as you claim they are, point your supervisors to that and hopefully, they'll start to get the point.
Perhaps you just need to record some metrics to get an idea of how well your programmers really are doing. Check out this article to get a little better idea of using LOC (lines of code) metrics and Function Point metrics. I'm not so sure that these would be the best metrics for this case, but there are lots of them, perhaps total man-hours or something similar to that. I found this quote at http://www.eds.com/news/home_page_itrendline.shtml, "People should be judged on output not by the number of hours worked. What it takes one person an hour to complete could take someone else five hours..." Here is another good article relating over-seas programmers with U.S. programmers.
All in all, the sentiment seems to be the same. Programming can't really be forced. Some things just take time and, no matter how long you make your programmers sit in their chairs, the projects aren't going to get done any faster. All that you'll accomplish is to "burn out" your programmers a little faster.
I don't know if I've been much help to you, Eduardo, but I sure do agree with you. Keep fighting the good fight. ;)
Update: More good links: Understanding Software Productivity, Effects on Programmer Productivity, Flow-Based Programming, Function Point FAQ
Skepticism is the source of knowledge as much as knowledge is the source of skepticism.