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

Re: Using Deming to Define Standard Work in Programming

Expand Messages
  • Matt
    ... Programming ... standar ... types ... Alan, I read your blog posting but I have not read the book. While I agree with the qualities you set up as goals
    Message 1 of 3 , Oct 21, 2007
    View Source
    • 0 Attachment
      --- In leanprogramming@yahoogroups.com, "Alan Shalloway"
      <alshall@...> wrote:
      > I just wrote a blog Using Deming to Define Standard Work in
      Programming
      > <http://netobjectivesblogs.com/2007/08/29/using-deming-to-define-
      standar\
      > d-work-in-programming/> that may be of interest to the developer
      types
      > who lurk on this user group.
      >
      > Alan Shalloway
      > CEO, Net Objectives

      Alan,

      I read your blog posting but I have not read the book. While I agree
      with the qualities you set up as goals and the principles designed to
      help achieve those goals, I am curious as to why you are seeking "the
      compelling argument that there are certain practices that just must
      be followed."

      Incidentally I do agree with the practices you list in the post and
      elsewhere (I attended your one day Denver conference last Friday...
      and highly recommend it to others.) That said, I am always leary of
      Lean thinkers who want to "lock in" the current state of a system.
      You said it yourself in one of the lectures, practices might change,
      but principles shouldn't. One of the primary tenets of Lean thinking
      is "flexibility."

      Since you mentioned systems thinking in your blog, let me explain my
      perspective in terms of a systems approach. The two absolutist
      approaches to standard work are 1) Predict all best practices by
      inducing them from the stated principles OR 2) Reject all best
      practices in favor of allowing them to emerge from the system as they
      most certainly will. Note that in both cases you *should* end up with
      the same set of standard work.

      A systems thinker (or relativist) will reject both approaches and
      recognize that the important structure is the *relationship* between
      the worker and the work itself rather than the practices used by the
      worker to accomplish the work. The story of the two brick layers
      told by Gerald Weinberg (and I am sure others) is illustrative of the
      point.

      <paraphrase>
      A minister asked two brick-layers what they were doing. The first
      said "laying bricks" but the second replied "I am building a
      cathedral!". The minister was impressed and wrote a sermon based on
      the inspiration of the second man. The next day he returned to the
      site and the second man was gone. He asked the first where he was
      and the man replied "he was fired, he thought we were building a
      cathedral but we are building a garage."
      </paraphrase>

      Both men were undoubtedly using standard work, however one had the
      wrong relationship with his work. So the worker may change, or the
      nature of the work itself may change but the principles shouldn't
      change, at the end of the day we are still laying bricks (or writing
      code!) If a programmer switches to a language that doesn't support
      one of the practices prescibed, she shouldn't abandon the principles
      defined but rather she should either induce a new set of practices
      from the principles or allow those practices to emerge. In either
      case they should arrive at a valid set of practices BUT this will
      only happen if the programmer has the proper relationship with her
      task of developing software.

      But what of the case where we have a priori knowledge that a set of
      practices DOES best fulfill a set of principles (either because we
      have induced from the principles or deduced from emergence in the
      past)? This seems to be the situation you are addressing in your
      blog (with no small amount of frustration I am sure!) Why do so many
      programmers refuse to "see the light" and insist on creating "God
      Objects", needlessly coupling classes and refusing to use a factory
      of any sort? My belief is that these programmers have the wrong
      relationship with software development. Either they don't understand
      what it is they are doing (writing high quality software that is
      maintainable in the future) or they are simply the wrong person for
      the job. In any case I think you will have far more success in
      encouraging people to implement "standard work" if you focus more on
      the relationship of the developer to his or her task.

      I am not arguing that the defining of a set of best practices in
      software development is a bad thing. My concern would only be if
      those practices were to gain the status of "principles". At the base
      level of an industry or organization, the day to day work habits of
      individuals should be continually improved via kaizen events,
      suggestion boxes or whatever means necessary to gather the most
      knowledge from the people with their "hands on the keyboards." As
      long as we allow our practices to continue to evolve in the light of
      the principles we have defined along with new knowledge gained, I
      think listing and implementing standard work is an excellent idea.

      By the way, in your presentation last week in Denver you did an
      excellent job, in my opinion, of building and / or reinforcing the
      proper relationship between the developers in attendance and the
      developing of software. In my post here I am "thinking out loud" so
      as always I would welcome anyone's perspective on the thoughts here.

      Matt
    • Alan Shalloway
      Matt: Thanks for your post. You might look at the conversation that took place between me, Mary Poppendieck and Pete Alvin on the Lean Development group. ...
      Message 2 of 3 , Oct 23, 2007
      View Source
      • 0 Attachment
        Matt:
        Thanks for your post.
        You might look at the "conversation" that took place between me, Mary
        Poppendieck and Pete Alvin on the Lean Development group.

        >Matt Said:
        > That said, I am always leary of
        > Lean thinkers who want to "lock in" the current state of a system.
        > You said it yourself in one of the lectures, practices might
        change,
        > but principles shouldn't. One of the primary tenets of Lean
        thinking
        > is "flexibility."

        I am definitely not trying to lock in a set of practices. I am
        trying to raise the bar to a set that has been proven to be
        valuable. From there, Lean practices would evolve it. But there
        isn't a reason to re-figure out good coding practices.

        > But what of the case where we have a priori knowledge that a set of
        > practices DOES best fulfill a set of principles (either because we
        > have induced from the principles or deduced from emergence in the
        > past)? This seems to be the situation you are addressing in your
        > blog (with no small amount of frustration I am sure!) Why do so
        many
        > programmers refuse to "see the light" and insist on creating "God
        > Objects", needlessly coupling classes and refusing to use a factory
        > of any sort? My belief is that these programmers have the wrong
        > relationship with software development. Either they don't
        understand
        > what it is they are doing (writing high quality software that is
        > maintainable in the future) or they are simply the wrong person for
        > the job. In any case I think you will have far more success in
        > encouraging people to implement "standard work" if you focus more
        on
        > the relationship of the developer to his or her task.

        Many developers do not follow the principle of optimize the whole.
        They merely want to optimize their part of the job - get code out
        fast without worrying about the maintenance. This is a travesty
        because it is faster to write high quality code than low quality code
        when you know how.

        While this is a great conversation, it involves more lean now than
        programming. Perhaps we should take it to the leanagilescrum group
        (the sister group to this one).


        Alan Shalloway
        CEO, Net Objectives
      Your message has been successfully submitted and would be delivered to recipients shortly.