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

Uncle Bob and Roy Miller on Control

Expand Messages
  • Dave Hoover
    I m finally reading Uncle Bob s new book, Agile Software Development Principles, Patterns, and Practices. It has been extremely educational. My lack of
    Message 1 of 4 , Feb 1, 2003
    • 0 Attachment
      I'm finally reading Uncle Bob's new book, "Agile Software Development
      Principles, Patterns, and Practices." It has been extremely educational.
      My lack of experience has kept me from digesting as much as I would like,
      but I have found his OO principles to be very instructive. I have never
      read anything on package design before and that blew my mind a bit. I'll
      probably need to re-read that a few times. It's great stuff.

      I was caught off guard today by the opening paragraph in the subsection
      titled "Metrics," on page 281:

      "To paraphrase Tom DeMarco [from 'Controlling Software Projects']: You can't
      manage what you can't control, and you can't control what you don't measure.
      To be effective software engineers or software managers, we must be able to
      control software development practice. If we don't measure it, however, we
      will never have that control."

      And the final sentence in the next paragraph:

      "The more metrics we gather, the more information we will have, and the more
      control we will eventually be able to exert."

      In the last few weeks, I have also been reading Roy Miller's
      work-in-progress, "Growing Software: Exploding the Myth of Prediction and
      Control." At first glance, Uncle Bob's ideas about control seem to
      contradict Roy's. I find this very interesting because like Uncle Bob, Roy
      references DeMarco.

      I wholeheartedly agree that metrics can provide engineers and managers with
      valuable information. I'm just curious whether Uncle Bob's ideas about
      control contradicts Roy's. What is Uncle Bob wanting to exert control over?

      From Roy's chapter on Control:

      "Managers are after certainty. Being certain about the future makes
      management easier. If you can't be certain, at least be reasonably sure and
      have a backup plan. But this desire for control produces an ironic outcome.
      Managers control the process right into the ditch. I call this the Software
      Uncertainty Principle:

      Your attempts to control interfere with the natural process that is going
      on, and throw it off track.

      The outcome can be fatal for projects. Traditional software development
      approaches are based on the idea of exercising control to produce certain,
      or least predictable outcomes. The problem is, those approaches assume an
      underlying linear reality based on simple cause and effect that doesn't
      exist."

      I would be very interested in hearing people's opinions on these two
      perspectives. I'm not exactly sure what Uncle Bob is trying to control, so
      I'm not sure if he and Roy are contradicting each other.

      --Dave
    • Ron Jeffries
      ... I don t think they are contradicting. I think they re both talking about steering, influencing, the project based on knowing what is going on in time to do
      Message 2 of 4 , Feb 2, 2003
      • 0 Attachment
        On Saturday, February 1, 2003, at 10:54:08 PM, Dave Hoover wrote:

        > I would be very interested in hearing people's opinions on these two
        > perspectives. I'm not exactly sure what Uncle Bob is trying to control, so
        > I'm not sure if he and Roy are contradicting each other.

        I don't think they are contradicting. I think they're both talking about
        steering, influencing, the project based on knowing what is going on in
        time to do something about it.

        Ron Jeffries
        www.XProgramming.com
        The rules are ways of thinking, not ways to avoid thinking.
      • Dave Hoover <dave@redsquirrel.com>
        Ron, ... I m getting hung up on the DeMarco paraphrase, You can t manage what you can t control. Is that necessarily true? I guess I m thinking of manage
        Message 3 of 4 , Feb 3, 2003
        • 0 Attachment
          Ron,

          > > I would be very interested in hearing people's opinions on these
          > > two perspectives. I'm not exactly sure what Uncle Bob is trying
          > > to control, so I'm not sure if he and Roy are contradicting each
          > > other.
          >
          > I don't think they are contradicting. I think they're both talking
          > about steering, influencing, the project based on knowing what is
          > going on in time to do something about it.

          I'm getting hung up on the DeMarco paraphrase, "You can't
          manage what you can't control." Is that necessarily true? I guess
          I'm thinking of "manage" in terms of an XP Coach and that's where the
          word "control" doesn't feel quite right. When I think of the role of
          Coach, I do not think of someone who focuses on control. I think of
          someone who encourages, guides, and pays attention to the process.

          "Every time you guide the team, you make them that much less self-
          reliant." --Kent Beck, "Extreme Programming Explained," page 145

          --Dave
        • jeffgrigg63132 <jgrigg@mo.net>
          ... Perhaps see and influence would be more appropriate for a coaching role. - jeff (Or You can t properly manage if you haven t a freakn clue. to be
          Message 4 of 4 , Feb 3, 2003
          • 0 Attachment
            --- "Dave Hoover <dave@r...>" <dave@r...> wrote:
            > I'm getting hung up on the DeMarco paraphrase, "You can't
            > manage what you can't control." Is that necessarily true?
            > I guess I'm thinking of "manage" in terms of an XP Coach
            > and that's where the word "control" doesn't feel quite right.
            > When I think of the role of Coach, I do not think of someone
            > who focuses on control. I think of someone who encourages,
            > guides, and pays attention to the process.
            >
            > "Every time you guide the team, you make them that much
            > less self-reliant." --Kent Beck, "Extreme Programming
            > Explained," page 145


            Perhaps "see and influence" would be more appropriate for a coaching
            role.
            - jeff








            (Or "You can't properly manage if you haven't a freakn' clue." to be
            excessively Dilbert-esque. ;-)
          Your message has been successfully submitted and would be delivered to recipients shortly.