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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.