A practice is something we, as a community, have discovered is simply always a good thing to do. For something to be promoted as a practice, it must be truly universal (you can always do it, and everyone should do it). Therefore, it must be:

1. Easy to do. We don’t want to burden ourselves or slow ourselves down because of a practice.
2. Easy to teach. If we want everyone to do them, it should not be a burden to propagate their use across the entire team, organization, and the profession itself.
3. Be highly valuable. A good practice should pay you back over and over and over again.

A common medical practice is all doctors wash their hands before dealing with their patients. It is not hard to do, it’s easy to teach others to do, and it has made the entire profession fundamentally more successful.

These are practices that meet all three of these standards.

Programming by Intention

The eXtreme Programming movement brought with it a set of practices that can help to keep code quality high without over-design or wasteful implementation. Similar to the concept of “top down programming” that was popular among Smalltalk and Cobol developers in the past, programming by intention essentially consists of creating methods by calling them, in consuming code, before they actually exist, and then implementing them afterward.

This simple procedure produces a surprisingly large number of positive results including:

• Method cohesion
• Good interface design
• Ease in subsequent refactoring
• More granular tests

…to name a few

For more, see Programming by Intention from our Essential Skills for the Agile Developer: A Guide to Better Programming and Design

Make state private

State variables should be made private by default. If there is the need to make an object’s state available to an outside entity, then accessor/mutator methods (in languages like Java) or properties (.Net) should be provided.

This prevents other entities from become coupled to the nature of the state (how it is stored, that it is stored at all, where it is stored, etc…).

Similarly, state that is intended to be accessed by a derived class should be kept private in the base class, but protected accessor/mutator methods or properties should be provided. This keeps derived classes from coupling to the nature of the state it the base class.

Encapsulate constructors

State variables should be made private by default. If there is the need to make an object’s state available to an outside entity, then accessor/mutator methods (in languages like Java) or properties (.Net) should be provided.

This prevents other entities from become coupled to the nature of the state (how it is stored, that it is stored at all, where it is stored, etc…).

Similarly, state that is intended to be accessed by a derived class should be kept private in the base class, but protected accessor/mutator methods or properties should be provided. This keeps derived classes from coupling to the nature of the state it the base class.

Perform Commonality-Variability Analysis

In his seminal work “Multi-Paradigm Design”, James Coplien suggested a technique for analyzing domains that tends to produce strong, useful abstractions that create architectural longevity and increase ROI. We feel this is such a valuable effort that we consider it a practice: Commonality-Variability Analysis.

It uses our natural ability to conceptualize complex elements in our environment to create opportunities for open-closed-ness in design.

When given a requirement ask the question, “How will I know I’ve done that?”

Many people think of Acceptance Test-Driven Development (ATDD) as an advanced practice. Others think that using Given When Then (GWT) from Behavior Driven Development (BDD) requires the use of tools. Neither of these are true however. The easiest way to start using ATDD and/or BDD is simply to ask the question “How will I know I’ve done that?” whenever you are given a requirement – even if the requirement appears to be obvious. The reason for this is that it is often the ‘obvious’ requirements that are most mis-understood.

Notice how this passes our “easy to do, easy to teach and highly valuable (at least at times)” criteria. It also starts you down the road of considering your behavior prior to implementation – and that’s a good thing.

See How to Start with ATDD using BDD for more.