What coding teaches us about branding

While quipping with my CIO and CTO last week about a curious rebranding case study in our industry, I said the brand doesn’t meet three branding/naming tests we are religious about: is it modern, comforting, and clearly say what the company does?

My CTO is especially religious about clarity, and reminded me that bad names prevent code from clearly communicating its intent. But if you get naming right, everything falls into place—just like with branding.

He sent me a post on coding that he’s referred to often recently while we’re working on a company rebranding of our own, and I want to share an excerpt here for anyone who’s racking their brain while coding or branding because it’s incredibly relevant for both:

Why naming is hard:

Anyone who has ever tried to name a child knows that naming is hard. Naming things in code is harder. It’s bad enough that you have to commit to a name that someone isn’t going to like. You also have to be able to live with it. In principle, the naming things in code need only be temporary, but names in code stick just like nicknames at school.

We could of course refactor our code to rename things any time we like, but we don’t do this enough in practice. We also find it hard to agree on what good names and bad names look like, which makes it hard to know when renaming improves a name. If we renamed things more often, then it probably wouldn’t be so hard to name them in the first place.

Unlike naming children, coding involves naming things on a daily basis. When you write code, naming things isn’t just hard, it’s a relentless demand for creativity. Fortunately, programmers are creative people.

Why naming matters:

Naming matters for both idealogical and practical reasons. First of all, we want names to exhibit truth and beauty: to be the right names, and to make our code clean and beautiful. At least, this is what we want to think about our code, but naming’s importance is far more practical.

Naming is communication. Bad names prevent code from clearly communicating its intent, which is why code with obfuscated names is spectacularly hard to understand. The compiler might not care, but the humans benefit from naming that communicates effectively.

Other people, including your future self, need to understand the code to be able to make changes. In many contexts, and for many teams, software maintenance provides the biggest day-to-day challenge. Scalability is the problem you want to have, and sooner rather than later, but maintainability is the problem you’re definitely going to have, sooner or later.

___
Reference:
– The Hardest Thing In Programming and the Great Naming Myth