I have been hit with this question hard and quite a number of times...simply because I cannot settle to call my work something like "file parser", "software testbed", etc....yeah...am refering to the ones I used to do at school. So, I used either abbreviations,
or mythological names which would have some relevance to the nature of work in the code or the functionality that the piece of code demonstrates.
Once I got into my day job at a small start-up, I realized that the management guys who also give demo's to the clients, have this funny notion of changing the name of the product all together. So, lets take a portal that deals with amount of money spent
by a medical company....on physicians, admin costs, maintenance, members, brokers, etc, we intially called "Utilization Management". Since I did not have much of a say in the name of the product, I and my collegues were coding our class namespaces with either
"UtilizationManagement" or "UM". Great ! all went on fine for a while, until one day the VP of marketting comes over, and asks us to change the title/name of the product/service to "Utilization Analyses" and another month later...he coined the term "Profyle".
Well..easy for him to say, and expect us to change the text accordingly in all the external facing web-pages, but what about all our code. Sometimes, a simple Find-Replace is going to be good enough, but is it something that one should do whenever something
of this sort happens?
Or, is it wise that we christen the product with a generic down-to-earth name which defines its functionality...like...in the above case..."UtilizationManagement" ?
And use your resource files to just change the text on the external facing pages ?
Now, we need to remember that using the above approach, would work ... well...to a certain extent.
Take the case of a big company...obviously, they would have thought through the whole product, and then give a code name to it, and later, rechristen it to a proper name. The same would not work for a smaller company, where in there is not always a fore-thought
as to what more is going to be added on to the product and at what time. The example given above where we talked about UtilizationManagement, which in reality represents only one small part of a huge product, a smaller company ... for the lack of resources
will just work on this for 2-3 years, and then maybe think of adding a module called "Disease Management"....and boom.....there needs to be some change to the existing code to make it co-exist with the newer module.
In a bigger company too...say Microsoft....when MS came out with their office suite, they did not have Visio....but after acquiring Visio, they decided to put it under the Office suite...how would they have done it????
What do you readers follow at your company???
Rant on...[6]
This has been posted at
http://community.dynacx.com/blogs/sashidhar/archive/2006/11/30/What-is-the-name-you-give-your-project_2F00_product-_3F00_.aspx
