I have been wondering for a few years now how to make the compelling argument that there are certain practices that just must be followed. In our design patterns courses we talk about code qualities, practices to get them, principles to guide the practices, and more:

Code qualities:

• readability
• strong cohesion
• loose coupling
• no redundancy
• encapsulation
• testability
• focus

Practices:

• Design to interfaces
• Programming by intention
• encapsulate construction
• ...

Principles:

• Open-Closed Principle
• Single Responsibility Principle
• Shalloway's Law and Shalloway's Principle
• ...

This is just a sampling of what we consider the minimum for a programmer to know before we'd consider him/her competent. In other words, we feel there are a basic set of competencies everyone should have and practices/principles they should follow. But how do you compete with - "well I like putting everything in one class because it is easier to understand?" Especially in the Agile world where the individual and team are supposedly king without question.

More recently, I've been trying to put this in Lean terms and thinking that these practices would be the standard work of the teams in an enterprise. They'd be things everyone should do. Or, perhaps better said, skills everyone would know and respect and then implement them in the best way possible in their own teams. Unfortunately, people take this to mean - "apply it when I want to". Not quite strong enough - sorry.

Well, I think I have it now. I've been reading Scholtes' The Leader's Handbook because Mary Poppendieck quoted some things from it and it sounded very valuable and thought provoking. My favorite was “All of the empowered, motivated, teamed-up, self-directed, incentivized, accountable, reengineered and reinvented people you can muster cannot compensate for a dysfunctional system.”In the book he talks about some necessary competencies of leaders in the new world.

Competency 1 is the ability to think in terms of systems and knowing how to lead systems.
Competency 2 is the ability to understand the variability of work in planning and problem solving.

In this one he discusses common cause and special cause. "Deming taught us that there are two types of variation. Common cause variation is built into the system and is the net result of multiple influences, many of which will never be known. Most variation - the problems, defects, errors, accidents, mistakes, waste, scrap and rework that we suffer on a daily basis - is common cause variation, built right into the system. Deming calls the other type of variation special cause variation, a unique event that is attributable to some knowable influence." (It's amazing how you can forget things you knew once. )

I would claim that not following established good practices (what I listed above is just the beginning, and definitely includes most XP coding practices as well) will add to the common cause variation. That is, not following these will result in errors because the system will have more variation in it and people will not work well enough to prevent the errors (e.g., coupling two classes may not cause a problem if someone happens to notice it but it'd be better not to force people to attend to the coupling). Expecting people to compensate for errors the system is causing is not a wise thing to do.

OK, I guess I can't prove the above practices fall into this category, but it gives us a good distinction on which practices should be followed by everyone. These are those practices that will reduce common cause errors. For example, will following the practice of encapsulating by convention, revealing only when you need to, reduce errors throughout the system? I (and a host of technical trainers and coaches worldwide) would agree that it will. What if your style doesn't like this? Sorry, doesn't matter. You should apply these practices with the intention of reducing common errors.

Anyway, more to go here, but I think I'm getting closer to making the compelling argument that we can define a subset, at least, of the standard work of software development and the distinctions we'll use to say whether they are part of this standard work or not.

If you have questions or comments re this blog, please comment on either our LeanProgramming user group or our LeanAgileScrum user group.

Alan Shalloway