If, within reason, my developers come in at 9:30 and feel like leaving at 4:00, it's fine with me. For I trust them enough to understand that if they are leaving, it is not because they are taking advantage of the situation, but because they feel that they are "done" for the day. These are the same developers that are sometimes at the office until 3 a.m., who are willing to work 16 hours on a weekend, who are willing to slave on a product, if need, be, to meet a deliverable. However, the management does not understand the nature of knowledge-work, and has given me some grief about how sometimes, *gasp* developers are not around at 4:00, or maybe they come in at 10.
Now, if deliverables were to start slipping, and I saw a general lack of responsiveness and a downgrade in quality, I would react with a more stringent set of requirements, however, until that time comes (which I hope is never, we have worked hard to put together a strong team, and a good atmosphere,) I refuse to bend on this.
However! My life would be made considerably easier, if I could present a series of arguments, from recognized professionals, and maybe a study or two, as to how the productivity of a shop that allows more psychological freedom can match (if not eclipse) one run under more draconian code.
I appreciate any anecdotes or pointers that you might be able to provide me with.
|
---|
Replies are listed 'Best First'. | |||
---|---|---|---|
Re: On programmer schedules and productivity
by tinman (Curate) on May 11, 2001 at 02:46 UTC | |||
Personally speaking, as a software developer, one of the major benefits of a job is the relaxed dress code and work hours.. I've put in my share of flat out, no sleep, caffeine driven work weeks, but I do appreciate being able to leave early when there is no work to be done.. Its nothing you can cite, of course, but I turned down a rather lucrative job offer when I graduated because the place operated under the draconian laws you mention, even to the extent of regulating the desktop wallpaper.. (the wallpaper, for heavens sake... that was *not* normal) Ok, onto the official stuff, well, when I was at university, a bunch of business studies students did a measurement on programmer productivity.. They focused on the concept of "flexitime", so I trawled around the web a bit and found a few links.. unfortunately, I doubt the actual study is online... Another place to look would probably be in HRM (Human Resource Management texts)..
| [reply] | ||
Re: On programmer schedules and productivity
by Sherlock (Deacon) on May 11, 2001 at 02:58 UTC | |||
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. ;) - Sherlock 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. | [reply] | ||
by idnopheq (Chaplain) on May 11, 2001 at 04:09 UTC | |||
Did that sound bitter? That acronym is still too fresh in my mind ... methinks I'm happy being happy elsewhere ... knowing that this all runs in cycles and the big boys w/ stuffed shirts will find themselves in a "world of pain", sooner rather than later. The quote DOES make nice copy for the shareholders, tho. UPDATE: please don't ++ this node ... it ain't worth it ... spend your valuable voting capital on something more worthy.
HTH
| [reply] | ||
Re: On programmer schedules and productivity
by footpad (Abbot) on May 11, 2001 at 03:32 UTC | |||
A few (somewhat) random thoughts come to mind: I would definitely discuss this with your boss and with your people. See if you can find (or negotiate) a compromise that satisfies everyone. Granted, you won't always be able to do so. But, I have found an active approach is better than a passive one. At the very least, it's worth a shot. --f | [reply] | ||
Re: On programmer schedules and productivity
by idnopheq (Chaplain) on May 11, 2001 at 03:13 UTC | |||
The problem with the more flexible approach at this time, IMHO, is the dot-com "fiasco". Too many upper-management types think the whole thing stemmed from the lax, "unprofessional" atmosphere within the workplace. Of course, it was flexible. The old mold of desk time meaning anything was long gone, and that is part of why such fledgeling companies could draw such tallent (obscene salary and benefits helped, too, no doubt). An associate left her position at a comfy, Fortune-500 company to start her own consulting gig. She and her partner started it with nothing but their own savings, no investors (beyond some family members, who were quickly paid back). She is a business school-educated manager w/ technical skills and her partner is the inverse. They turned a profit w/i two months, due to a solid business plan and the ability to acquire qualified start-up cast-offs as employees. Now, a year down the road, with cash reserves and an ever increasing clientelle, she cannot get additional funding to acquire more infrastructure. The anti-investors pointed out the flexible work environment as the main problem and "would you please fix that". Is this appropriate? No, I don't think so. But, I have no money to invest and have not been stung by the NASDAQ, so these folks' milage indeed does vary. I look at my old employer, who only a few years ago made the "no suit" leap. People still flood out of there, even with an uncertain future. Why? THEY HATE THE ENVIRONMENT and LIFE IS TOO SHORT. The moral of this tail is a management philosophy I employed in my bleek "I'm the boss" days: If the work gets done, it is quality work, we make money, we take care of the customer, and the staff is content - let it be. As managers, make the expectations clear and let folks take care of business. If it means they can cut out at 4:00 to hit the links or whatever, so be it ... One aspect of management I could never stomache was the busy bee scenario, anywho. "That's just my opinion. I could be wrong." - DM
HTH
| [reply] | ||
Re: On programmer schedules and productivity
by jepri (Parson) on May 11, 2001 at 06:05 UTC | |||
I am relatiely new to the ways of companies, but I have noticed that there are always a couple of truely superb technicians/programmers wandering around, who had much leeway in ordering their affairs - but they were insanely dedicated and got the job done, often under conditions that would have other people handing in their resignations - such as working a month with no break (all weekends), late nights, whatever was necessary. This was partially due to their relationship with the managers, who made it clear that they understood give and take - on the late nights the managers would sometimes show up with beer and pizza. However after DEC was bought out, management practises changed, to the point where one worker was reputed to have told his boss that if he wasn't transferred in a month, he'd quit. I regret that I can't offer you a positive story on how good management improved productivity, I can only recount what I have observed, that poor management and a focus on improving profits has driven away the good workers. Perhaps you could use this as a cautionary tale. Your main problem appears to be that you are dealing with people who have no idea of what is going on, so they need to measure something to convince themselves that they are getting value for their money. I wish you the best of luck in explaining the development process. ____________________ | [reply] | ||
Re (tilly) 1: On programmer schedules and productivity
by tilly (Archbishop) on May 11, 2001 at 19:36 UTC | |||
You are a programmer. You write a program. You put it out into production. A week later something doesn't work right. But you are not in. Nobody knows where you are. Nobody knows how to get hold of you. Whatever broke is important. Things that need to get done - that people are relying on getting done - are not. And this is a very visible failure. Massive overtime is a morale and productivity killer. I agree. Being able to choose your own schedule is a huge morale boost. Absolutely. And motivated developers will get more done when they have that flexibility. But what is motivating these managers is not just the desire to be obstinant control freaks. It is the observation that when people work together, and need to interact together, having them not mutually available while they are working is itself a morale and productivity killer. And most workers do not have the flexibility that people in IT do to do their work when they want. Secretaries need to be around when people will call. Sales staff need to be around when prospects can be reached. Lawyers need to be around when people have questions on contracts, negotiations are happening, etc. Support staff need to be around when people need support. And so on. Most of these jobs require knowledge just like IT. In fact quite a few of these jobs require substantially more knowledge than IT - as is evidenced by the fact that people can (and do) get into IT without a specific education while people do not (for instance) become doctors or lawyers without a heck of a lot of training. Or stay as such without constantly staying abreast of their field. These people have claims that are better than IT for truly being "knowledge workers". So the moral is this. Evaluate what you are doing and what your tasks are. Evaluate how you do or do not have to be available to interact with people. If you truly do not need to ask questions, be available for trouble-shooting, etc, then indeed individual productivity is the only thing that matters. But if you depend on other people or other people depend on you, there may be a real need (or sometimes just as importantly a perceived need) for you to be available at predictable times. Note that available does not always mean present. It does not always mean that everyone has to be available. But that is the need that needs to be addressed, and unless you address it you will encounter quite a bit of resistance. In addition remember that IT is unusual in that people can be productive on unorthodox schedules. This conflicts with what people from other departments will have seen, heard, and experienced in every other field. Be aware of this. Do not lose sight of this. After all if you do not know why the other person feels as they do, then you will not know how to address their concerns. Finally note that this is not a criticism of attempting to make times flexible. The benefits that people have talked about exist and are very real. Rather I am pointing out why flexible schedules are a potential problem so that you can decide what and where you can give head off real concerns while maintaining flexible hours. | [reply] | ||
by eduardo (Curate) on May 11, 2001 at 19:48 UTC | |||
And I certainly don't think that your position is contrary. In my original post I said: If, within reason, my developers come in at 9:30 and feel like leaving at 4:00, it's fine with me. For I trust them enough to understand that if they are leaving, it is not because they are taking advantage of the situation, but because they feel that they are "done" for the day. and *that* is the key. Within reason. Programming is 50% knowledge work, and 50% communication, there needs to exist a series of metrics to guarantee that the communication is happening, it's facilitated, and it does not incur such a level of overhead that it hampers the progress of the organization as a software development shop. My qualm with the other execs was not: "I think my programmers should come and go as they please" but, "If deliverables are being produced at the rate that we have set down in our predictions as optimal, then we should alow them a degree of freedom which alows them to feel ownership in a product, and highly valued resources. I actually thank you quite a bit for bringing this point up. Yes, individual productivity is important, but the holistic productivity of the company as an entity, is equally (if not more) important. I just happen to believe that the organization, as a whole, will be considerably healthier if we are willing to be flexible and understand the stress of knowledge work, rather than attempting to pidgeonhole, compartmentalize, and commoditize the art and science of "good software development." That said, of course, the art of "good software development" isn't just some programmer in the back at 3 a.m. living off Mt. Dew pounding out 5k lines a day... it's organization, it's communication, it's job satisfaction, it's client satisfaction, it's the knowledge of a job well done, and it's the knowledge that when you come back in tomorrow, you will accomplish something, you will grow as a professional, and your clients will value the work that you have done for them. Again, ++ to tilly, we certainly don't disagree, the right answer usually lies in balance :) UPDATE: In tilly's comment, he said: You are a programmer. You write a program. You put it out into production. A week later something doesn't work right. But you are not in. Nobody knows where you are. Nobody knows how to get hold of you. Whatever broke is important. Things that need to get done - that people are relying on getting done - are not And I wanted to actually address that. There are quite a few ways to mitigate that, one of course is the distribution of knowledge about products developed. I am attempting to tackle this right now by implementing some aspects of the much discussed XP methodology in my company, namely, peer programming. I am very reticent to have any piece of software that is developed under me have the intellectual property locked inside just *one* person, as the beer truck theory is a very real thing. (In other words, what happens if the developer with the knowledge gets run over by a beer truck!) Hopefully by successfully implemeting peer programming, we will minimize the single points of failure that make a scenario like the one you just described less likely. In an organization where you have a good requirements management methodology, and you are doing your best to manage client expectations, I am personally less interested in catering and optimizing my business processes to the statistical outliers (I wrote a program, It was rolled out into prod, after 1 week of going fine, the SQA signoff, the unit tests passing, etc... it somehow stops working) but to the day to day operations of a software development shop. I am more interested in optimizing the "average case" productivity, than I am in guaranteeing availability of a developer in case of a chaotic event, after all, if Murphy's law plays any part of this, if the catastrophic event does happen, chances are the developer will be out of pocket for some other reason :) Again, we agree 100%, the right answer lies in compromise, communication, and understanding. UPDATE 2: The perticular vertical of knowledge worker I was referring to in this case, was not support staff, or sales engineers, or project managers, or even systems architects. The group of people I was *most* concerned with were the *actual* developers, those are the ones that to me can be qualified as almost pure knowledge workers. | [reply] | ||
by tilly (Archbishop) on May 11, 2001 at 21:28 UTC | |||
Allow me to explain. Bonds tend to pay on the 15'th, 20'th, and 25'th. Most companies in finance have to mark their portfolios to market on the last day of each month. Where I work, these facts set the basic rhythm of life. An ideal rollout therefore works like this. First week of a month it can be tested by end users. You try to do the upgrade that weekend. On Monday people any needed cleanup and further configuration has to happen. A week later developers hopefully have nothing to do, but they need to be around for any questions that might arise. Even if it is just a question on how to type a command. Or as major as having your database get unacceptably slow when everyone is hitting it at once. So when I said a week later, I wasn't invoking Murphy and pulling a number out of thin air. I was pointing out the expected pattern of usage that I see. Oh, and (in response to update 2) I work in a small company. In a small company people tend to do multiple things. Internal developers are not segregated from support. If you develop something, you might not field calls from customers, but you will receive feedback. And, of course, with internal products your users expect to be able to talk to you. After all if you added an option to a utility used by 4 people, who else are they going to ask? As well developers need to be responsive to the unexpected. For a random example, it doesn't matter how technically perfect your XML news feed is or how long it has been working as it flawlessly. If the upstream provider slips banner ads into their feed (accidentally or not, doesn't matter) then the system needs to learn how to strip them. Now. (Hopefully you keep this kind of stuff to a minimum, but sometimes things happen outside of your control...) Now in your environment these specifics may be irrelevant. But they aren't for me... | [reply] | ||
Re: On programmer schedules and productivity
by Mungbeans (Pilgrim) on May 11, 2001 at 15:00 UTC | |||
After doing several projects, I noticed the following points about my work: IT is a knowledge industry. It is very hard to measure the productivity of a coder. You have to rely on the motivation and the professionalism of the coder - and you therefore have to strenuously resist any initiative that may piss off that coder. Motivation is fragile, and very difficult to recapture. What works for me is when my boss shows an active interest in my work, and gives positive feedback - 'the customers think this interface is really easy to use and intuitive', 'would this have been easier if it was done OOP?'. I really enjoy working hard when people appreciate my efforts (regardless of the £££s). This has been a sample of 1 however so not statistically valid. | [reply] | ||
by lachoy (Parson) on May 11, 2001 at 16:04 UTC | |||
All this reminds me of the whole discussion on mappers versus packers (partucularly in Chapter 1). It's difficult for non-software-development people to understand the process of development -- to them, it sometimes looks like we're just goofing off and if they were just able to get us to apply ourselves we'd be that much more productive. One of the problems is that code isn't an easy product to create metrics for. Sure, there's quantity, and sure, there's output (does it do what it's supposed to?), but I think non-development people always have the suspicion that it could always do more and that it's the lazy developer's fault it doesn't. Chris | [reply] | ||
by orkysoft (Friar) on May 11, 2001 at 21:01 UTC | |||
I really enjoy working hard when people appreciate my efforts (regardless of the £££s). True. I just finished Mapster: The Next Generation, with many useful features and much faster loading. This is quite a complicated program, and I didn't get paid a dime to make it, but the appreciation of the people who use it fueled my determination to finish it greatly. | [reply] | ||
Re: On programmer schedules and productivity
by LD2 (Curate) on May 11, 2001 at 05:33 UTC | |||
| [reply] | ||
Re: On programmer schedules and productivity
by snafu (Chaplain) on May 11, 2001 at 10:36 UTC | |||
either way, I am not being productive or as productive as I could be. I like your style of thinking and wish that more employers/supervisors would recognize the same thing. Some people are different. Some can code all day and stay on the ball. Don't get me wrong. I can code all day long too....but not for two weeks in a row all day long. I have to take a rest in there or I just get too burnt out. When there is a deadline in place I get the project done when it needs to be done. However, coding is like art. It is never perfect the first time. You have to rest from it now and then to keep the mind clear and focused so that the work is eventually the best it will be. Update: It would seem that you would be able to use us as statistical backing beit not very ... numerable but backing nonetheless. We all (save one or two maybe) are in the development field...(I Love it!!!!).
---------- | [reply] | ||
Re: On programmer schedules and productivity
by Mission (Hermit) on May 11, 2001 at 17:56 UTC | |||
| [reply] | ||
Re: On programmer schedules and productivity
by virtualsue (Vicar) on May 11, 2001 at 15:31 UTC | |||
This being the case, stand firm and make them give you good reasons why you need to change anything. It sounds as though everything in your department is working perfectly well so your critics are the ones who need to prove their case, not you. Keep pointing out that you are meeting all your milestones and that all your numbers add up. Wild guess: Are any of the execs who are trying to manage your group for you having problems in their own departments? | [reply] | ||
Re: On programmer schedules and productivity: The view of a Uni Coop
by Ducati (Beadle) on May 11, 2001 at 17:53 UTC | |||
I have been woking in the flex system since I was a highschool summer student. At first I was suprised that I could come in at 10 and then leave at 4 if I felt that I had everything done that needed to get done. I began to see the real benifit of this system when my position was extened to a part-time job. As long as I put in all of my hours and completed my projects on time, there was no worries about when I came in... or left. This was a real benifit because I could manage school and work effectivly. This ment that I could keep my grades up and make money at the same time. This didn't apply for the usual part-time jobs that I had worked. As I moved on to University I really came to appreciate the flex system. Mostly it was for the same reasons as mentioned above; grades and money. It also allowed me to get some 'real-word' experience because I was involed in some 'real' projects. If classes were done early or I had big breaks in my schedule I would come into work for a few hours. Again, as long as I put in my time and completed all my projects, all was cool. Along the way I have worked full time in the summers. When you are at work all day and under the gun the last thin that you want is more pressure. Sometimes I would put in long, long days for weeks on end, but when I needed a rest I took advantage of the flex system. It really saved me from burn out. I think that it also takes pressure off of managers, if the system is used properly. This way management doesn't have to check-up on their employees to see if they were in at 8am and didn't leave before 4pm. As you can see, the flex system has worked well for me and I have seen much success with it. However, I have also seen the down side. Employees that misuse the system. It can create problems for the rest of the team. If the team is using the system properly then the gears will turn properly, but if a team member is not pulling thier weight then things begin to break down. This is no different than the traditional system, but it is harder to pin point the root of the problem. Management then has to spend more time to find out why things are not as smooth as they once were. In conclusion, through my experiences I think that the flex system is a great idea and works really well. Let it be known that I have worked more in the flex system then out of it, but the positions that I have had that follow the flex paradigm have been far beter than those who follow the old system. I guess that I am considered the new breed of employee in a totally different work environment from that of even a decade ago. It is exciting to see where the work environment will evolve or possibly digress from here. I hope that this view helps your case. If you want more info, or need a test case, please feel free to /msg me and we can get in contact. Ducati
============================================ "We rock the body to rock the party ... until the party rocks the body" De La Soul | [reply] | ||
Re: On programmer schedules and productivity
by coreolyn (Parson) on May 11, 2001 at 19:19 UTC | |||
As I've worked in almost every environment from home-business, startup VAR/ISP's, to Cubicle corporation I feel compelled to share my thoughts on this informative node. Of course my great boss walked by the cubicle while I was entering this and I got the evil eye *sigh*... coreolynOh well back to the java ... | [reply] | ||
Re: On programmer schedules and productivity
by AidanLee (Chaplain) on May 11, 2001 at 18:13 UTC | |||
That said, there is something to be said for negotiating so that employees are working at roughly the same time. I know from personal experience that it can be hard to sync with your co-workers if they're on completely opposite schedules. Though that is not the premise of this thread anyways. | [reply] |