Yes, coding *is* a zero-sum game, Robert…

Scoble questions whether greater community engagement really takes away from time that developers have to spend on other things like fixing bugs. I would have to agree with John Cavnar-Johnson on this one: from personal experience, blogging and other community engagement like the newsgroups does suck time away from other activities that I could be pursuing like designing new features, writing new code or fixing bugs. I don’t think Scoble is totally off base with his “all work and no play makes Jack a very dull boy” thesis, but I think that that model only really applies to the creative end of development which is only one part of the overall work it takes to get a product out of the door. A huge chunk of the product development cycle is, indeed, one-step-after-another work where you just have to get the damn work done. And if you’re busy blogging, you’re not doing that.

That being said, I am reminded of the famous Churchill quote, “Democracy is the worst form of government except for all the other forms that have been tried.” As in, yeah, it sucks that community engagement takes time away from other things, but what’s the better alternative? Robert has it right that community engagement provides valuable insight to both us and the community, and so even if it’s a zero-sum game in terms of developer time, I still think everyone comes out ahead.

Which, I suppose, was Robert’s original point. OK, I guess it’s time for me to go back to doing something useful…

8 thoughts on “Yes, coding *is* a zero-sum game, Robert…

  1. Ryan Lowe

    Consider the alternative though: you just code, code, code and code. You get a requirements definition, make some specs and then code them. The customer never gets involved, never has any input. How do you know you’re not on the right track? You don’t. Taking user feedback as early as possible to mitigate risk sounds like a pretty good use of developer time to me.

    It doesn’t take coding time away from the developer, it just makes coding more valuable, useful and highly concentrated. Coding with your head in the sand is a crapshoot. Even fixing bugs can benefit from increased customer interaction.

    I think we’re all in agreement, this is just another perspective on the same thing. 🙂

    Reply
  2. paulvick

    I should add that my perspective is an internal Microsoft one, where we have a division of labor between developers and Program Managers. It’s the job of the PM to make sure that the customer is involved and has input, partially so that the developers can focus on coding. In the case where there are no PMs, I’d totally agree that a developer needs to play both roles…

    Reply
  3. John Cavnar-Johnson

    I just want to clarify that my comments were in response to Alex Lowe’s original post about what Microsoft should be doing to help developers. That is, I was trying to draw out the tradeoffs inherent some specific suggestions he was making. Talking about resource allocation at the corporate level is very different than talking about how teams or individuals allocate their time.

    Reply
  4. Ryan Lowe

    Paul: And then you have communication overhead between PMs and developers, right? So that takes away from coding as well. The more coders on the project, the more communication that is necessary to sustain it — verbally, email, paper specs, etc.

    It would be interesting to see this broken down into a sort of time-motion study, where the different approaches were analyzed to see which ones were the most effective (best code for the buck).

    If the developers themselves are communicating directly with the clients on a specific problem instead of having to go through the PM (after all, it’s the developers who know the nitty gritty of it), does that save more time than having everything go through the PM? The PM can only interact with the customer so much — he has other work to do too. 🙂

    Reply
  5. Mike Schinkel

    Ryan: Not that I don’t somewhat agree with your premise, but playing devil’s advocate, if every developers on the team communicated with customers, teach would come up with different ideas for direction and we’d have "too many cooks in the kitchen." For a project to be successful, you need a common vision, one that hopefully the PM provides in MS’ case.

    Reply
  6. Ryan Lowe

    I’ll all for a singular, well-communicated vision but that doesn’t mean the PM makes all of the decisions or should be the only person communicating with the customer(s) or end users. He would be the productivity bottleneck of the project.

    Reply
  7. Joku

    When it comes to feedback, I have tried to think it like: Only if I’m sure my feedback applies to a particular area, and I happen to see MS blogger which states he is a PM/Lead dev in that area, then I go directly to him.

    In this case I also use the CTP Whidbey to verify does the problem apply to it also. Otherwise I have tried to use the less direct approach.

    But I can see the problem with this approach. Imagine if everyone using IE would mail directly to the IE people without any person in between filtering or "re-targeting" the feedback.

    The direct approach seems best reserved to the case when you can be quite sure it applies to the team you are sending the feedback to, as is the case when the person you are mailing to has for example blogged that he is working on this area (Whidbey Help for example).

    Reply
  8. komsun

    When it comes to feedback, I have tried to think it like: Only if I’m sure my feedback applies to a particular area, and I happen to see MS blogger which states he is a PM/Lead dev in that area, then I go directly to him.

    In this case I also use the CTP Whidbey to verify does the problem apply to it also. Otherwise I have tried to use the less direct approach.

    But I can see the problem with this approach. Imagine if everyone using IE would mail directly to the IE people without any person in between filtering or "re-targeting" the feedback.

    The direct approach seems best reserved to the case when you can be quite sure it applies to the team you are sending the feedback to, as is the case when the person you are mailing to has for example blogged that he is working on this area (Whidbey Help for example).

    Reply

Leave a Reply