Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Kate Oneal on Productivity

Expand Messages
  • John A. De Goes
    Hi Ron, ... Honestly, I got it from other postings you have made. Specifically, one in which you questioned that time freed up would be spent productively. ...
    Message 1 of 192 , Mar 1, 2008
    • 0 Attachment
      Hi Ron,

      On Feb 27, 2008, at 11:19 AM, Ron Jeffries wrote:
      > Where did you get "can't trust"? Kate has two reasons for
      > suggesting that graph. (Note that she did not ask for it.)
      >

      Honestly, I got it from other postings you have made. Specifically,
      one in which you questioned that time freed up would be spent
      productively.

      > > If you've succeeded in creating an enjoyable working environment for
      > > your employees, then I take it as a given that the vast majority of
      > > any time they free up will be spent productively. Developers hate
      > > tedious work. All forms of waste are tedious, because they involve
      > > doing things that theoretically don't need to be done. As you remove
      > > waste, tedium decreases, and developers are able to enjoy their job
      > > *more*.
      >
      > That turns out not to be the case. /Some/ programmers are likely to
      > build tools. In my nearly half-century of building super working
      > environments, the majority do not build tools. A larger fraction
      > will look for tools to download and try.
      >

      I never said developers are likely to invest effort into eliminating
      tedium. I said they are happier when tedium is eliminated.

      I share your observation that few developers build tools that
      eliminate waste. Most, as you say, look for tools they can use (which
      is a good first instinct; using someone else's tool saves you a lot
      more time than writing your own). However, I think this is a
      consequence of management by numbers and a strong emphasis on short-
      term results.

      What developer is going to take a week to build a tool that will save
      10 minutes a day for every developer on the team? Likely, it would be
      in the best long-term interests of the company to invest in such a
      tool, since break-even occurs after just 2 months (assuming a
      reasonable-sized team). But it's not in the best interests of the
      individual developer, who will have to show zero progress in the tasks
      assigned to him (in a non-agile environment), or have to take on no
      stories (in an agile environment). There's too much pressure for
      developers to engage in such risky behavior, generally.

      But not always. At one company I worked at, there was a developer who
      *did* build such tools. He would often put many hours into creating
      scripts that automated tedious activities. Many of these scripts were
      such time savers, they quickly spread to the whole team (50+
      developers, distributed across several continents).

      However, he often put in 60-80 hour work weeks, so he could report
      progress on the tasks assigned him, while simultaneously increasing
      the efficiency of development. Not many developers are willing or able
      to do that.

      Regards,

      John A. De Goes
      N-BRAIN, Inc.
      http://www.n-brain.net
      [n minds are better than n-1]
    • Ron Jeffries
      ... I freely grant that having someone come in and point to issues in the code is helpful. But I ve never seen a team where none of them knew they were
      Message 192 of 192 , Mar 10, 2008
      • 0 Attachment
        Hello, Steven. On Friday, March 7, 2008, at 8:23:05 PM, you wrote:

        >> Why do you say this? Every team I've ever had anything to do with
        >> knew when it was producing crap.

        > Ron,

        > Before you had associated with them, or only after you had
        > enlightened them?

        I freely grant that having someone come in and point to issues in
        the code is helpful. But I've never seen a team where none of them
        knew they were producing junk. Of course, I only see teams who are
        at least somewhat aware that they need help.

        > I have encountered quite a few teams this century who were quite
        > openly proud of their cleverly engineered proprietary DAO, not
        > understanding that they had in reality wasted several person-months
        > creating something inferior to freely available frameworks like
        > Hibernate and whose maintenance was going to degrade their velocity
        > until they finally gave up their pride and replaced it with
        > (N)Hibernate (or the equivalent).

        > Seriously, you have not encountered this phenomenon?

        You describe a phenomenon illustrating my point, where a team
        realizes that their home-grown DAO is holding them back. Yes. It's
        an example of teams figuring out that they are producing / have
        produced crap.

        And my guess is that some of them knew long before, and quite
        possibly even said so. If a team is any good at all, at least some
        of them know.

        Ron Jeffries
        www.XProgramming.com
        If you don't have the courage to say what you think,
        there isn't much use in thinking it, is there?
        --Thomas Jay Peckish II
      Your message has been successfully submitted and would be delivered to recipients shortly.