When designing and building software, abstraction or naming entities accurately pays big dividends. The payoff comes from lowering the total cost of maintainability and also from increased software quality.
It is said that if you can't describe something, you don't understand it. In the software world, making sure that the design (and code) is understandable by a human is paramount to extensibily and to maintainability.
We have a continuous push for software to do more and more. Without continuous abstracting (naming) we, as architects and developers, would not be able to satisfy this increasing demand. Generally, abstraction should rise in direct proportion to rising complexity, otherwise, advancement will come to a screeching halt.
Not understanding a design in other word bad naming, translates to rigidity, hard to maintain software, slow to extend features, lack of conceptual integrity, inconsistency in features and unsatisfactory user experience.
Starting from architecture to coding, naming your entities accurately is a corner stone of superb software design quality.
Learn to make paying attention to naming as part of the design process and this habit will not only clarify your design in your own mind and to others, but will also open up new feature path or extension points that would be totally missed otherwise.
To start with, you can apply this design-by-naming methodology by mirroring real world entities to software entity names.
Go over those entity names and refine them to make sure their names exactly fit their function or purpose. This is not as easy as it sounds and deep analysis is required here. For example, is it really a 'payment' or a 'transaction'? If you call it a transaction, this implies that later you can sub type it into a payment. On the other hand, if you call it a payment then it cannot be used as an invoice transaction anymore. Careful naming has many implications on design as you can see.
Once you name your software entities in a name-for-purpose fashion, the next step is to use Pure Fabrication to highly increase your software's stability and extensibility. This step is usually what differentiates great software from mediocre software.
Look for those clumsily or unclear design areas that do not clearly map to a real world entity and fabricate new entity names for them. This is the fun part and a source of software excellence.
Let's use the classic example of an Undo feature. In the beginning, maybe it won't be clear to you how to implement it in a clean and extensible way. This is where the art of naming comes to the rescue. If we fabricate a new entity and name it 'Action' using that to represent a user action, then we can cleanly slap on it an Undo method where the undo implementation details will reside.
In this manner, by using proper naming (or abstraction), we didn't just implement the undo feature in a clean encapsulated way, but we also opened up the extensibility path to add more features on a user action such as Send, Store, Forward etc...
Using design by naming does not just improve design and quality, it also improves software readability and maintainability and therefore lowering total cost of ownership. The above 'Undo' feature example shows how it made it easier to maintain the software. The things that can be done on a user action are conceptually packed in one area. The design and code is now easy to understand and extend. As an additional bonus, the design and code will be highly readable because the entity names are self explanatory and don't need much documentation.