Misnamed Interfaces

Problem: You found out that the name of a frequently-used interface is poorly chosen.

Potential Solutions:

Find all references and change them all
- Pro: Fixes problem if all occurrences found
- Con: We may miss some occurrences, resulting in crashes
Leave it alone and make a note somewhere that has the good meaning.

(Based on a usenet discussion. Will clean on a later date.)

 > >>This sort of situation is actually rather common at the enterprise
 > >>level.
 > >
 > >
 > > Changing names of columns but keeping the semantics is extremely rare,
 > > just because it breaks the interface to the applications.
 >
 > So do all changes to enterprise schemas, which is why /any/ change to
 > such a schema is a big deal. The DBA already had to change the schema
 > to provide burdenedSalary and chose that opportunity to clean up the
 > semantics.

Perhaps I missed the purpose of this debate, but changing the name of *any* interface in any paradigm or language can result in headaches. We use names to reference things. If 50 other applications or routines or classes refer to "fooSalary" and we later realize that it should have been called "barSalary", then we are faced with a *universal* dilemma of whether to hunt down and change all 50 references, or leave it with a bad name. This is not a problem unique to databases.

I generally suggest leaving it with the bad name and putting a note in the schema (if provided) or routine or class about the actual nature of the misnamed thing. If you try to hunt down all references, you may miss some and your boss will be pissed when things break.

The only universal way around this dilemma that I see is to use "dumb keys", names that carry no meaning and so can't have the wrong meaning by design. However, it is hard to conceptual work with variables and interfaces with names like "A348282" and "SDFASD".

-- top

The OpenSource method for renaming a published interface is to use deprecation and time to heal the wound.

First, release the new renamed interface and mark the old one as deprecated, so you get warnings when you use it. Also remove references to the old interface from any documentation. This prevents new code from using the old interface.

Then use as much time as you require to incrementally move all uses of the old interface to the new interface.

Periodically send out feelers to check whether the old interface has completely withered. When it has, you can finally make a release that removes the deprecated interface altogether.

As far as DB schemas, if DB's allwed column-level views, not just table views, then perhaps one could create a synonym and then slowly change it over time as you work on various apps for *other* purposes. This is the "under the radar" approach that won't anger your boss, and allows you to test each change more carefully because you have to test it for other changes anyhow. --top

CategoryInterface, CategoryNaming