Keep Mass Low

Documentation and code are both mass. More mass means greater inertia. Greater inertia means more energy is required to change direction. We know that changes in direction will be frequent and necessary. You have a limited amount of energy. Therefore, keep mass as low as possible (but no lower) in order to make changes in direction consume less energy. In that way, you will be more productive than those who create too much code or documentation.

Sometimes, high mass is necessary: You can't get to the moon using chemical rockets unless they're big. But do make sure you need to go to the moon, and make sure there aren't better ways to get there.

... keep mass as low as possible (but no lower) ...

Surely you can't keep the mass lower than as low as possible, because, um, like, it's impossible. By definition. Surely? So I'm not really sure what this is saying. Is this like saying that someone should give 110%? Are you being serious or facetious? It's just a clever way to say "keep mass just right" or "don't get so zealous in reducing documentation that you throw out the baby with the bathwater"

Generally, "but no lower" is programmerese for "without making the solution less correct". You can make the mass "lower than possible" by cutting corners and making assumptions. If you were building an RDBMS, "as fast as possible but no faster" means the highest speed you get while still keeping ACID constraints. You could make a system "faster than possible" by dropping the Atomicity or Durability requirements."

Some say that the kind of "mass" that increases inertia is not the number of characters or lines. These people figure that the kind of "mass" that's problematic is the number of concepts, particularly the number of redundant concepts. See: RedundancyIsInertia.

Mass > inertia > energy ... is this a Mass Low hierarchy?

Groan.

Extending the original thought:

Mass (of the solution) - Mass (of the problem) should be as small as possible. -- DonBranson