- AcmeCorporationBlah
- AcmeCorporationBlahBlah
- AcmeCorporationBlahBlahBlah
- AcmeCorporationBlahBlahBlahBlah
- Qaz102AcmeCorporationBlah
- Qaz102AcmeCorporationBlahBlah
- Qaz102AcmeCorporationBlahBlahBlah.
I asked my colleagues the significance of this number and was told it was version 1.02 of the Qaz databases.
The thing is, there exist no version 101s, 103s or even 100s, neither in production nor in any other environment. In fact, every time one of these 'Qaz' databases occurs, the 102 is blindly included in the name.
I asked if the '102' was strictly necessary and the entire team looked at each other and shrugged. I then asked if we would ever deploy different versions of the QAZ databases for the same customer and was told, no, that would never happen. I then asked how long the 102 had been in the names and none of them knew. It predated them all, and the dev manager.
Since my current task involves deploying the databases for a new customer, I asked if I could omit the 102 from the QAZ database names. Now they all looked at each other and looked reproachful.
"No, that's the standard," one of them said. "Why do you want to take it out; just because you don't like it?"
"No," I replied. "I want to take it out because it's adding a small amount of unnecessary complexity to the domain."
He raised his eyebrows, said "Wow!" and turned back to his workstation shaking his head.
And that was the end of the conversation.
So now I'm propagating this fallacious learned behaviour and I'm irked; irked enough to write this blog post.
In the same way that code smells accumulate to clutter our code base, bad learned behaviours accumulate to clutter our working practices.
We should refactor the bad smells out of both.
Often.
