http://qs321.pair.com?node_id=79745


in reply to On programmer schedules and productivity

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.

Replies are listed 'Best First'.
Re: Re (tilly) 1: On programmer schedules and productivity
by eduardo (Curate) on May 11, 2001 at 19:48 UTC
    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...