"The beginning of wisdom is the ability to call things by their right names" -Confucius
Fantasy novel magicians and software developers all know how important names are. Once you know someone’s True Name, you gain tremendous power over them and can make them do anything you want – spin straw into gold or sing “O Canada” backward. Software developers are so invested in names that we spend 84% of our time thinking of great labels for variables, functions, classes, components, tables, collections, and foil balls (the other 16% is spent changing the state of bugs in Jira). The name tells the reader what to expect out of the entity just conjured.
The importance of the name grows with the scope and longevity of that name. Thus a variable might have as simple a name as I. While the name of a component will be more descriptive, like NationalAnthemReverser. A descriptive name not only helps developers predict how the component behaves but also how it should change in the future.
Despite the industry having finally realized the relationship between team structure and architecture, we still struggle with team names. I once had 17 feature teams reporting to me who were descriptively named 0 through 16; they were each in turn part of larger teams that were named after colours. I wished briefly that we had chosen butch cats for the larger teams, but team names were quickly encoded in surprising places, and may as well have been written in stone by the time I took to cat fancy. We had a huge chart to describe the components and features that each team was responsible for, and even so, there were always tasks that fell on boundaries or outside anyone’s accountability. It seemed the more we tried to define the teams, the bigger the gaps between them became.
With poor team names, it was impossible to reason about them, and a baffling mystery to a new layer of senior management when they started. Frequently, we found it difficult to decide where a boundary task should go. The scope of responsibility for a team was a cohesive list of components or features, but there was no guide indicating why a new component or feature should be added to one list rather than another.
My preference today is to name teams after business goals. That usually aligns with the product management structure, and makes it clear what should be important to the team. Tasks still land on the boundary all the time, but there is a clear signpost to provide direction off the boundary. With goal-aligned team names, other parts of the organization can imagine what a team might do, and the teams become much easier to reason about.
It’s still not perfect, but unless they’re hockey stars, anything is better than calling your team “Panthers.”
Thank you Rene for writing this, and if you're interested in more of his writing check out his WordPress here.
Want more interesting content from a variety of sources from our VP, Engineering to or CEO? Subscribe to our newsletter below!