Lightning Talk: “Naming Things Is Hard”: A Guide to Naming Using Network Science - Nick Travaglini

This talk discusses the importance of naming conventions in the context of Open Telemetry instrumentation. The speaker, Nick, highlights the challenges of effectively naming spans and other elements in order to enhance debugging capabilities in production environments. Drawing upon scientific research, he presents a model that allows for collaboration among teams to create a shared language for naming. The talk explores a study that compares decentralized and centralized networks for name generation and proposes that a connected broker model achieves both speed and effectiveness. Practical takeaways include the value of leveraging diverse approaches to improve naming strategies in software instrumentation.

Thank you all so much for coming out. We're going to talk about how to name things and we're going to use some scientific research that's been published to help us create the best, most effective names when you're instrumenting with Open Telemetry. All right, this is the run of show. I'm going to tell you who I am. We're going to talk about the problem and define the problem

in some more detail. We'll talk about what resources exist today. We'll get into what the actual science says. Uh talk about some practical takeaways and then we'll wrap it up. Who am I? My name's Nick. He/him pronouns. I work as a senior technical customer success manager at honeycomb.io. Thank you all for coming out today. Uh and what's the problem? So, the problem Open Telemetry, great project, amazing

standard, there's so much flexibility here. In order to instrument your software services effectively, you need to make sure that those names do you uh favors. And uh as you're customizing your instrumentation, you need to make sure that your team can pick out parts of the service in a way that lets you uh effectively debug in production. Uh and we're going to cover some ways that you can

uh do that naming. So, what resources exist today to help you figure out how to effectively name uh your spans, for example? Well, the Open Telemetry project has some resources, a series of blocks. These are great. I highly recommend that you go read them. They're one method for thinking about how to effectively name telemetry. This is going to be another method, complementary. What does the network science

say? Well, first of all, let's just think about this. There's instrumenting your services and there's the syntax and the the uh what you're actually writing and then there's how you come up with the names in the first place. And we're going to look at your team and how your team can effectively collaborate in order to come up with the best names. We're going to look at this

particular paper. You got the citation here. You can read it in more detail afterwards. Well, I'm going to cover a lot of the details here. What we're going to talk about is creating a shared language and how you can most effectively organize yourselves to create what they call a shared language, names and naming conventions. Well, how they start off in the research literature, there's a paradox. Both

a totally decentralized network of people and a centralized with a single person, single node or broker are supposed to produce the best names or shared language. And they're like, how is this possible? How can they both be the best? Well, they hypothesize that we should actually disambiguate what the best means. Horizontally, you see the rate at which the the team comes up with the name. Totally decentralized

comes up with names fastest in their hypothesis. Um, and but a centralized team is slower cuz there's the bottleneck of the single broker, but people get time to explore and test out new names individually before they arrive at it their names. And so, they come up with the more effective names, more descriptive, help them pick out ambiguous situations. So, you can disambiguate the two and get best.

So, they want to test this hypothesis. They want to see is this in fact the case? Is disambiguating going to help us here? And so, they come up with an experiment. What they want is for a teams of people to get together, groups of five, and they have to name, they have to describe these tandems, which are just abstract symbols. And some of them are easier to

distinguish, others are more ambiguous. You can see some examples of names up there that people came up with. And an effective name will get you that quickly and pick out the ambiguous ones. They test with a few different network configurations from totally decentralized to centralized on a spectrum. Note the connected broker versus the disconnected broker. And they run their experiment. They want people these teams to pick

them out. What do they find? The connected broker network, the one that is just slightly more centralized than decentralized, is fastest. It's actually faster than decentralized. And it's at least as effective as the totally centralized one. So, you get the best of both worlds if you go with that centralized or uh connected broker model. Practical takeaways. You get to benefit from difference here. You get the best

of both worlds. You get to explore and you get to synthesize and come up with those that synthesis quickly if you take this connected So, consider this when you're trying to come up with names in instrumenting your software. Caveat, this is a laboratory experiment. Your results may vary in the wild. So, please try this out and share your results in forums like this. It'll help us all

get better. In conclusion, uh thank you for coming out. If you want to talk about this or observability in general, you can find me at the Honeycomb booth. And that's it. Thank you.