What's in a Name?

I had a conversation with a colleague at work over the name of some constants in a class. The colleague made a comment that went something like this

I would suggest we keep the constants named as thisUnclearName here in ThisClass. If anyone asks why it’s thisUnclearName we can direct them to OtherTeamInCompany and not us.

I went through a couple of reactions to this advice.

No Biggie

I wasn’t all that attached to the name change so I agreed. I had made a bunch of other changes in this pull request. This was no big deal.

Dirty

Later, I sensed that I had done something dirty. To cover our team’s ass, I had agreed to not improve the clarity of the code. Naming things is hard in programming and I had chance to make the intent clearer to future maintainers of the system. My colleague did not suggest a better name. My colleague suggested we maneuver so that another team gets the blame for the bad naming. Are we not ultimately on the same team?

Incentives Matter

This company has been around over 20 years. It’s a large system with a lot of technical debt and cruft. There have been many re-orgs and re-re-orgs and re-re-orgs. There have been several rounds of layoffs in the last couple of years. Most of my time at the company there hasn’t been clear concrete strategy of what we are doing and why we are doing it. It’s been slogans as strategy and catchphrases as tactics.

I think the company has a clear strategy now. But my colleague has been with the company for over 7 years. He is a survivor. He was sharing an adaptation to the environment that has helped him survive. We don’t know if this new strategy won’t be a slogan in a couple of months. And so if someone asks why thisUnclearName is used in ThisClass we will politely direct them to OtherTeamInCompany.