|
|
|
|
|
|
by alphast0rm
2228 days ago
|
|
|
One of my last teams used gods from Greek mythology (e.g. Apollo [1], Ares [2]), and another nearby team used Pokemon names. Lots of folks started using similar naming conventions and eventually a clear naming manifesto was sent to all engineers to discourage this practice for new services. It's much easier to discuss and reason about complex systems when the names are self-explanatory, especially when you get to 100s or 1000s of names. [1] https://www.memsql.com/blog/case-study-scalable-sql-database... [2] https://eng.uber.com/aresdb/ |
|
|
* It is often most critical to differentiate between things that have similar functions. The relevant distinctions will not be clear by the time of naming (i.e., this is the part that used to manage the whole X but now just responds to callers, this is the part that was separated out from the old X for scaling, this is the old X backend, this is the older backend that runs for the old platform Xes only...).
* The same name may seem to make sense to people for very, very different things. (Viz. how many technical meanings "migration" has) If you have to namespace your names to get over this, Org Product Name starts getting clunky enough it will be called something different in practice anyway.
In sum, I would say that it's much easier to discuss and reason about complex systems made up of parts with clear divisions of responsibility, and I'm sure that everything tends to be easier when those divisions have been static enough over time such that the names can still correspond to responsibilities. However, I will take every single Pokemon name in existence over the confusion caused by names that try to describe what services do and are inaccurate.