Last night a friend of mine pointed me to the 97 things wiki and an interesting axiom “A rose by any other name will end up as a cabbage“. The axiom page talked about how you should name the components in a software project. The idea arises from a simple argument “If you don’t know what it is to be called you don’t know what it is”.
In my opinion natural languages are the best tools for describing the requirements of a project. Although diagrams are very helpful in explaining the overall logic or flow, but the details of the requirement should always be explained in natural language such as plain English. When requirements are written in plain English, you can toss the requirements across users for comments and get feedback at an early stage of software development. Not all users can understand the complexities of state machines, use case diagrams, ER diagrams etc. but all of them understand, jargon free simple English. Yes, you can use any other natural language than English, when working with non-English speaking population.
Another advantage of using a natural language to describe requirement is that you get a natural abstraction layer called ‘name’. When you name something you try to come up with a mental abstraction based on the major characteristics of a (physical) object and second time you have to refer to same object or collection of characteristics you call it by a name, instead of long description of the object. When you see a repeating pattern, give that a name. When you see a bunch of instructions to be executed repeatedly give it a name. When you see an interface, give it a name. At the same time ensure that the name is specific enough to convey the characteristics (eg. cheap,fast,easy, strong etc.) of the abstraction or object. A name that is not specific enough points to lack of clarity in the abstraction layer and is a sign of either too much of abstraction in the system or over engineering. At the same time you need not build abstraction only when you see lots of features being clubbed. An interface might implement only two or three features but the frequency of repetition of those features will make them as a candidate for abstraction and thus a name.
Creating abstraction comes natural to all the humans and it is easy for us to identify things by a name. May be that is why we came up with an idea of commands to computers because it was easier for a human to remember a single command instead of typing a set of instructions to see a list of files in a directory for example. We further progressed into creating scripts which would be a collection of commands (essentially an abstraction), giving name to a script and then remembering the name as a command.
When you are designing a new software, having a specific name for a component will create the abstraction automatically. But do watch out if you have too many names in your requirements, you might be suffering from over engineering and you might have created too many abstractions…
Who says whats in the name ?