Saturday, January 24, 2004

Class Ownership #2 - Preventing Atrophy

Code reviewing can be revealing! This can be especially true when done on a project which is a little unusual or run under stressed circumstances.

As I pointed out yesterday, class ownership introduces a constraint. When code needs to be written in a hurry, the class owner may not be available. There are two choices: wait for the class owner to free up; or allow a non-owner to check-out the class and make an update. When you are against the gun, there is little choice - break the class ownership constraint.

However, there is a price to pay. This price is not immediately obvious. In fact the systems cycle before it becomes an issue is so delayed and far removed that the cause and effect are hard to associate. Nevertheless, the quality of a class will atrophy unless the code is peer reviewed by knowledgeable team members. I found a great little example of this recently. A developer had opened another’s class and added a very short method to complete a sequence. The method directly accessed a member variable (private attribute) of the class. Elsewhere there was a friendly scoped accessor method. All the rest of the class was using this method. Why? Naturally, the class owner had a reason - in a future release of the software, the attribute would not be accessed but calculated by calling out over the object model to other classes. By accessing the variable directly a potential future defect was introduced. This would inevitably cause some head-scratching later on and it is unlikely that enough information would have been captured in comments or design documents to really explain why something was one way and something else another.

The point in this example is that here is one small isolated incident. When you allow anyone on a team (particularly a bigger team) to edit any class for any purpose, you will quickly lose design integrity of the class. Paul Szego calls this “losing the Zen of the class”.

It is truly important that classes themselves are considered components and that as such they are designed with the rigor which goes into larger components. This is best done by having one architect* for the component - one owner for the class.

[*Reference: Brooks, Frederick, The Mythical Man Month, Addison Wesley 1995, Chapter 4 Aristocracy, Democracy and System Design]