Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

On programmer schedules and productivity

by eduardo (Curate)
on May 11, 2001 at 02:31 UTC ( #79591=perlmeditation: print w/ replies, xml ) Need Help??

I am the VP of a software development shop in transition right now. At one point this was a staffing firm, and it is just now undergoing the transition from staffing (a very interrupt driven workflow) to software engineering / development (a considerably more methodology based workflow.) Unfortunately, a lot of the management still has the pre/industrial mindset that productivity == seat time. I happen to feel otherwise. I have a hard time, ethically, imposing antiquated industrial methods for measuring worker effectiveness, on workers in what is basically a knowledge economy.

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.

Comment on On programmer schedules and productivity
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)..
    Disclaimer: I have no idea how respected the authors of the following articles are.. YMMV

    Flexitime benefits
    Flexitime study

    A Google search on Flexitime is where I got these links from.. btw :o)
    HTH

Re: On programmer schedules and productivity
by Sherlock (Deacon) on May 11, 2001 at 02:58 UTC
    Amen Eduardo!

    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.
      "Fortune 500 companies should not be judged by the output of their web pages and speaches by folks with golden parachutes, but on how they actually implement that which they pronounce as holy doctrine versus the way it really is on the front lines." - me

      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
      --
      idnopheq
      Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

Re: On programmer schedules and productivity
by idnopheq (Chaplain) on May 11, 2001 at 03:13 UTC
    This was covered in Hackers, Writers, and Productivity. But, in order to beat the expired equine ...

    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
    --
    idnopheq
    Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

Re: On programmer schedules and productivity
by footpad (Monsignor) on May 11, 2001 at 03:32 UTC

    A few (somewhat) random thoughts come to mind:

    • Since you're getting static from other managers, you may be able to quiet them a bit by showing them the amount of hours your people are logging against a project, assuming that you're tracking time. (If not, that may be another metric, one perhaps more appropriate than lines of code produced).

      clemburg posted some good ideas in this node. If you're tracking time, then it shouldn't be any trouble to draw up some pretty graphs for your "counterparts." Also, if you're using a VCS, you might consider analyzing the change log to see if there's an improvement to the number of changes checked in under your "flextime" experiment, as opposed to "normal working hours." Similarly, compare the bug database statistics under the "flextime" arrangment to the statistics under a more "traditional" one. I suspect you'll find the former provides better numbers.

    • Don't ding people because they don't put in the extreme hours. For example, I'm a parent. You're not going to get me to give up my weekends with my daughter very easily--if at all.

      This doesn't mean that I'm disloyal to your project, just that I'm not willing to give up my personal time as easily as I was when I was ten years younger, single, and less mathematically experienced.

      Keep this in mind when evaluating your people and the amounts of time they give you. Different people have different priorities.

    • If you reward the hardest workers, e.g. the ones logging the most hours, make sure you don't overlook others who don't put in extreme amounts of time.

      Remember, employment is a two-way contract, one best managed with mutual respect. Treat your people as adults, give them reasonable expectations, communicate those expectations, and then track how well they meet your expectations. Do not judge one employee's performance against that of another.

    • Don't expect extreme accomplishments. Regardless of how far beyond your expectations a person goes on a given project, problem, or process, each situation is unique and you need to judge your people by the same yardstick, even the superheroes.

    • Finally, there's the old "I trust my people; don't you trust yours?" argument. As long as you and your team are doing what you're asked to do and producing things to the satisfaction of your sponsors and the person you report to, the opinion of the other managers doesn't really matter.

      Please note that it's a very fine line to walk, one that must be handled with diplomacy. I'm not a terribly diplomatic person, but I will defend the arrangements I make with my direct reports, provided I can defend their efforts.

      Perhaps you might spin it as an investment or something more appealing to a bean counter. I'll leave that to your imagination.

    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

Re: On programmer schedules and productivity
by LD2 (Curate) on May 11, 2001 at 05:33 UTC
    I think that most programmers enjoy their work due to the flexible schedule. Although that sometimes means working at odd hours - but sometimes one doesn't "get their groove" until 7pm or midnight or whenever. As long as productivity isn't falling, I don't think management should have a problem. Out of curiousity, would they have a problem if developers came in at 7:30 or 7am or so and left at 4pm? That's an 8hr day or so... is their gripe that they're not in office during business hours or that they have shorter or longer days? Just for the heck of it.. this is interesting.. it was passed along in an IT department How Software Companies Die.. - Managment may or may not find this interesting. :)
Re: On programmer schedules and productivity
by jepri (Parson) on May 11, 2001 at 06:05 UTC
    One of my friends was recently (last Friday) chewed out for showing up to work at 11:30 - after he worked back to 2am the night before to get the job done. From his point of view, he was (metaphorically) slapped in the face for going the extra mile, and is now quietly seeking employment elsewhere.

    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.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

Re: On programmer schedules and productivity
by snafu (Chaplain) on May 11, 2001 at 10:36 UTC
    I know from personal experience that there are times where my brain simply cannot take the thought process anymore. So, its either you let me go and come back tomorrow refreshed or make me stay and one of two things happens:

  • The code sucks and I will spend tomorrow fixing it. or...
  • I will look like Im coding and really be surfing the web or something (perhaps working on another project)...the ole boss button...er command *shrug*
  • 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!!!!).

    ----------
    - Jim

Re: On programmer schedules and productivity
by Mungbeans (Pilgrim) on May 11, 2001 at 15:00 UTC
    My 2p.

    After doing several projects, I noticed the following points about my work:

    • I do the same amount of work in a 50 hour week as I do in a 60 hour week.
    • If I'm motivated I can do a 50 hour week in 40 hours, and get out the door early to enjoy the sunshine and all is good.
    • The quality of my work declines markedly after 50 hours, and it takes me longer to do even simple stuff.
    • If I have an employer who is flexible, I'm happy to put the extra hours when it is required. If I get mucked about over time sheets I get annoyed and start to slack off.
    • The good project managers that I have worked with have judged my performance by my output, not by bum on seat time.
    • The more time I spend away from work, the more creative and lateral I am.

    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.

      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
      M-x auto-bs-mode

      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.

Re: On programmer schedules and productivity
by virtualsue (Vicar) on May 11, 2001 at 15:31 UTC
    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.

    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?

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

Re: On programmer schedules and productivity
by Mission (Hermit) on May 11, 2001 at 17:56 UTC
    I manage a staff of web developers (all students) at a unveristy. I've gone through something very similar in the past two years. Here's my take on this issue in general and what I did to solve it.

    BOTTOM LINE: They're my staff! I work with them the way I think is best. When my upper management told me to change something about my staff, I shielded my staff from those blows. I completely blocked upper management's fingers from them. I didn't do this because I'm on a power trip. I did this to protect my staff!

    Upper management will never understand that you can't have a sterile environment with all workers sitting for exactly 8 hours at their desk all orderly, prim, and propper! It doens't work that way for the creative employees AKA: your knowledge-workers. I tried for two years to get my management to understand that what works for other non-creative (knowledge-worker) employees doesn't work for my staff. So I started to stonewall their access to my staff. I can tell you it was not initially well received, but I presented it in this way, which was positive, and did give my management what they wanted.

     As management, you are very busy doing a wide variety of things. My speciality and my job / commission is to oversee this particular staff of computer specialists. I can limit you're frustrations, and concerns, by telling you that I will manage the staff to the best of my ability. I'll handle that staff for you, so you don't need to worry about them. They will be more productive if we limit their distractions. You can talk to me at any time, and I'll be able to update you what is going on with the projects that we are currently working on. This way we can keep their productivity up.


    I can tell you that it was a strange moment, but it did two things for me. Firstly, it gave the managment the thing they wanted, someone is taking care of it, so "I don't have to worry." Secondly, it gave me what I wanted, the freedom to do the things that will make my staff happier, and more productive. I've had to correct management just a few times after the initial change, but after they understood that I meant hand's off, they just dealt with me, and I handled the rest.

    I don't know if that would work in every situation, but I know that for my and my employees, it worked out just fine.

    - Mission
    "Heck I don't know how to do it either, but do you think that's going to stop me?!!"
Re: On programmer schedules and productivity
by AidanLee (Chaplain) on May 11, 2001 at 18:13 UTC
    I think something to keep in mind is that the output of knowledge work is highly sensitive to the focus and entheusiasm put in by those doing the work. Commanding people to get focused exactly when you'd like them to be focused isn't necessarily going to fly. Better to accomidate and discover (or let the employees discover) when it is that they can be most focused, and under what conditions. If they're just not "on" from say 2:30 to 4:30, but are really on at 9am and 6pm, then so be it.

    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.

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.

    • As noted in Sherlock's comments and links, software development productivity is still an impossible gauge to measure. I wish management would do an exercise where each manager is give 1 day to draw a self portrait with the requirement that they log all of thier time as accurately as possible from finding tools to interuptions. Then all get together the next day and compare the logs and pictures. When they can find a way to quantitatively compare those results then they may have the tools to manage programming hours
    • On the other hand self-discipline is the key to personal productivity. A programmer that isn't pushing their own limits in this area generally is falling behind. I can't escape the irony of trying to figure out how this post itself is hypocrytical to my own self-discipline

    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 ...
Re (tilly) 1: On programmer schedules and productivity
by tilly (Archbishop) on May 11, 2001 at 19:36 UTC
    I am going to dare to offer the contrary position.

    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.

      Agreed tilly! 100% and ++. There is of course a balance to be reached, that balance will not be found with: "Let the programmers do whatever they damned well please, and the programs will spring forth whole, like Athena from the Brow of Zeus!" (I knew a manager like that once, scary...)

      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.
        I think we work in very different environments. In my experience it is not at all unlikely that new code can be rolled out, but a potential problem won't be noticed or a basic question will not arise until a week later. This is particularly true for applications which (like much stuff I get to support) are used on a monthly schedule.

        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...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://79591]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2014-07-30 07:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (229 votes), past polls