Zero: if a condition, circumstance, requirement does not exist, then no code should exist (commented or uncommented) to deal with it. This is true for requirements we haven’t seen (future proofing), but is also true for requirements which have some and gone. When a test, function, variable, or class has zero uses, it must be deleted. Recognizing the power of zero helps us keep our code clean.

One: A condition or class, event or circumstance, role or behavior exists, and so we must code for it. There is a limit on how much insulation and abstraction is needed. We can keep things very simple. Moving from zero to one (adding a requirement) is the typical operation, but moving from one to zero also happens.

Many: More than one is “many”. You might as well consider adding a list and/or interfaces. In design, some things repeat and some do not. Those that repeat are likely to continue repeating. Therefore, many is represented first by the value of two. Where there are many, there needs to be some insulation. The open-closed principle tells us that we should open the system for extension. The usual case in design is moving from one to many, but sometimes one will move in the opposite direction by removing interfaces or lists.

The transitions in either direction are important design events.