Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Re (tilly) 1: On programmer schedules and productivity

by eduardo (Curate)
on May 11, 2001 at 19:48 UTC ( [id://79748]=note: print w/replies, xml ) Need Help??

in reply to Re (tilly) 1: On programmer schedules and productivity
in thread On programmer schedules and productivity

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.
  • Comment on Re: Re (tilly) 1: On programmer schedules and productivity

Replies are listed 'Best First'.
Re (tilly) 3: On programmer schedules and productivity
by tilly (Archbishop) on May 11, 2001 at 21:28 UTC
    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?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://79748]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-05-22 09:22 GMT
Find Nodes?
    Voting Booth?

    No recent polls found