So, I got to thinking again about one of my pet notions - names/identifiers - and the unreasonable amount of time IT people spend naming things, then mapping them to other names, then putting the names into categories that are .... named.... aliasing, mapping, binding, bundling, unbundling, currying, lamdizing, serializing, reifying, templating, substituting, duck-typing, shimming, wrapping...
We do it for all forms of data. We do it for all forms of algorithmic expression. We name everything. We name 'em over and over again. And we keep changing the names as our ideas change, and the task to be accomplished changes, and the state of the data changes....
It gets overwhelming. And when it does, we have a tendency to make matters worse by adding another layer of names. A new data description language. A new DSL. A new pre-processor.
Adding a new layer of names often *feels* like progress. But it often is not, in my experience.
Removing the need for layers of names is one of the great skills in IT in my opinion. It is so undervalued, the skill doesn't have um, a, name.
I am torn between thinking that this is just *perfect* and thinking it is unfortunate.
2 comments:
Sean,
Very thoughtful post, as usual.
This one in particular resonated with me.
One of the most frustrating things I run into is when an additional layer of names has been added for no good reason or by accident. It increases the complexity of the code/data and the cognitive energy needed to understand it.
Often when I research why that additional layer was added, I find that it was because the developer didn't fully understand the layer underneath, often because that layer was already a mess.
This issue reinforces to me the importance of team communication and a shared grammar for a system that the entire team fully understands. It makes the design simpler. It makes the implementation simpler. It makes on-going maintenance simpler. Simpler is better. A simpler system is easier to change. and that makes the system last longer as a useful tool within the organization.
Unfortunately, in the real world, we often have to atone for the sins of others in this department. In our quest for "simplicity", we often add an additional name layer. This is sometimes unavoidable when the underlying name layer is not under our control.
However, when the underlying layer is under our control, I agree that we should seriously consider changing it (or removing it) before adding another on top of it.
I also agree that this skill is not possessed (or sought after) by enough developers. I often tell my team members that my favorite refactoring tool is the DELETE key. They laugh, and agree that getting rid of that garbage code that we have been living with for far too long would be a good thing. What they don't do enough is use that key themselves. I strongly believe that a developer's contribution to a project shouldn't be measured by the number of lines of code they have added, but by the number of lines they have deleted.
Hi Sean
This post resonated with me also. The frustration in not having a clear glossary of terms and resultant confusion, wasted time, bugs etc. drove me to have a business logic layer explicitly focused on naming. I called it a glossary and wrote up some thoughts a couple of years ago: https://unlearnbybimal.wordpress.com/2014/10/14/the-concepts-of-an-executable-glossary/
Warren - I share your experience and desire to delete too!
Post a Comment