Well, it's been rather a long time since the previous installment in this mini-series - almost two-and-a-half years in fact - so I hope this one is worth the wait...
In the project I've been working on I've struggled with naming components. People either inferred too much from the names, or they ceased to have the correct meaning as time passed, or a combination of the two. And just to make it worse other teams complained no end if we kept changing them. In the end we started using code names, with no real meaning at all, and that seemed to help a bit.
What I'd like to propose today is taking this one stage further and using people's names. The examples in the title are taken from the puzzle books of my youth, but there is precedent as well in the naming of hurricanes and other strong winds. The advantages I see are:
- Like with other code names, people cannot lazily infer meaning but must take at least a cursory glance at the code and/or documentation, which is likely to give a much more accurate idea of what a component does
- Components will start to acquire a "personality", so that people are better able to judge where functionality really belongs
- Another aspect of that personality is that it ought to be more apparent when to "retire" a component and "hire" a new one as opposed to "retraining" an existing one
Am I going completely mad, or might there be something in this? Has anyone tried anything similar? Either way I might give it a try sometime...
