--- In email@example.com
, "Alan Shalloway"
> I just wrote a blog Using Deming to Define Standard Work in
> d-work-in-programming/> that may be of interest to the developer
> who lurk on this user group.
> 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.