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.


blog comments powered by Disqus
Next Post
What makes a Developer?  01 May 2010
Prior Post
Spoken Numbers  15 Apr 2010
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
April 2010