New Rule: If You Can’t Name It, You Don’t Need It

When creating new software it is important to give simple meaningful names to the features and concepts that we create.  This allows us to communicate effectively with other team members and, more importantly, the users.  It can sometimes be difficult to give names to all of our concepts.  I believe that this is because modern software combines both established concepts that are familiar to the users as well as evolutionary ideas that were often not possible without computers.

It is important that we take care not to introduce more new concepts than are actually necessary to the user.  In the past I have seen features that have concepts with names like “base configurations”, “templates”, and “flavors” while the user only cares about the simple overall feature.  I have also seen vague lower level ideas like “pipelines”, “modules”, and “reflection” exposed to the customers.  Introducing ideas like these will usually just confuse the user (and often other engineers) while providing no actual value.

If you are considering adding something to your system and are having difficulty giving it a name, you probably don’t need it.  If your features do not mirror existing concepts in the user’s domain or established software patterns you are either adding unneeded complexity or developing revolutionary new designs.  I would not bet on the latter very often.