On Naming and Convention ...

Richard Dingwall has a good blog post talking about one specific case where a naming convention goes bad and starts hindering, instead of helping, development.

He writes:

One consequence … is that, now days, naming a class SomeSortOfDto doesn’t tell me much about what the object is for — only that the object carries data, and has no behavior.

Leaving Richard the last word on his specific case, there’s a good point to be abstracted out for other situations:

Any development convention is worth only as much as the net value it currently returns.

This directly leads to a number of interesting corollaries …

• If your convention returns a lot of value for relatively little effort, then you have a winner: keep doing it.

• If your convention involves significant effort, and no longer returns much value then you should drop the convention if you possibly can. A good example would be a convention that requires 8.3 filenames for all your source code. Back in the days of Windows 3.11 this was less of a convention and more of a requirement. Now, not so much.

• If your convention now delivers little value because it’s been misused or overused, then perhaps you need to reconsider - replacement with two or three better defined conventions might be an idea.

At the heart of this process must be the ongoing goal of continuous improvement: Always seek to do things better - but remember to keep yesterdays lessons.