Re: Using Deming to Define Standard Work in Programming
- --- In firstname.lastname@example.org, "Alan Shalloway"
> I just wrote a blog Using Deming to Define Standard Work inProgramming
> d-work-in-programming/> that may be of interest to the developertypes
> who lurk on this user group.Alan,
> Alan Shalloway
> CEO, Net Objectives
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
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
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
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."
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.
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.
> 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
> but principles shouldn't. One of the primary tenets of Leanthinking
> 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 ofmany
> 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
> programmers refuse to "see the light" and insist on creating "Godunderstand
> 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
> what it is they are doing (writing high quality software that ison
> 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
> 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).
CEO, Net Objectives