Can you afford naming mistakes?
I usually don’t. I know that if I choose wrong name for a class, project or service, I am going to spend time on hating them later. And if there are several people in the team who have strong feelings about proper naming, they are going to bring back wrong naming issues and use their precious time on it. So unless the project is shipped, and names it exposes become a contract that you can’t violate, it’s worth sorting out all uncertanties about naming convention.
There is however an argument that name corrections should not have high priority because it’s just a refactoring that don’t change a thing in functionality. But does it really cost so much to fix wrong name that you should postpone it (and potentially increase the cost of change)? I tried to measure one such change.
Yesterday I revised one of our services that provided validation of payment limits. Originally it was placed in PaymentEngine/Limits folder, and the WCF service it exposed was called just Limits. It was decided to relocate WCF services and revise their names to better reflect its business purposes, so I moved the project to a new place under Services/LimtsValidation. The change also affected several configuration and Wix deployment files.
Right after I was done with my changes, one of my colleague commented that “LimitsValidation” is not the best name. If we apply the same guidelines and styles we use for other projects, we should call it “LimitValidation”, with the word “limit” in singular form. After a short discussion I agreed but added that I won’t correct the name now, and maybe we should just live with “LimitsValidation”. Well, it’s not a big deal, is it?
But when I came back home, I realized that it will be difficult for me to cope with a wrong name that I admitted was wrong. And the best time to fix it would be now, when I still remember what I did and which files I changed.
So today I came to work earlier and corrected spelling of the service name and related files. This is what it cost me:
- Files changed: 22 (including changes in projects, folders, namespaces, configuration and deployment files)
- Time spent: 25 minutes (including execution of selected integration tests to validate availability of affected services after the change)
As you see, it did not take much time to correct a naming mistake, but it would take much more if the correction was postponed until it no longer remained an internal matter. Then it could even become too costly to afford.