One important aspect of maintaining existing software is determining which features to add, maintain, or remove and which bug fixes to prioritize. This process can be vague if done without any information about how the end users utilize the software. A survey is one way to measure this, but it is difficult to determine if survey results represent the entire spectrum of end users and their use cases. Enter software telemetry: an automated way to gather data on the use and performance of software and its components. With software telemetry, developers can receive usage data directly from customers, including performance metrics, exception logging, and usage patterns. This data in turn allows developers to be more responsive to the end users’ needs. However, like every software component in a complex system, there are considerations to be made.

There are different ways to introduce telemetry into a software application. There are out-of-the-box solutions that could be used, such as Microsoft Application Insights, which is suitable for most .NET applications or web applications that run on Azure. It can also be implemented from scratch within the software itself to give developers greater control over the telemetry logic and endpoints. Either way it is implemented, software telemetry can grant certain benefits.

The primary benefit of telemetry is the ability to gather accurate data directly from end users. The collection of data is fully automated, requires no interaction from the developers, and happens continuously as the user uses the software. Furthermore, the data can be aggregated into general trends and use cases; can be turned into queryable, digestible formats; or further refined into visual aids, such as charts or graphs, to share with management. This makes it easier to identify the use cases, potential new features, or bug fixes the software might need. In fact, telemetry can be used as one of the main driving forces for deciding features/bug fixes or how to prioritize them for the software development team. In return, the development team also becomes more reactive to the end users’ needs and pain points. All these benefits can be acquired with few drawbacks when software telemetry is implemented correctly.

Software telemetry is most commonly used to measure certain performance metrics and usage of features within the software. Common performance metrics include CPU/memory/disk usage, network I/O frequency, cloud resources status, etc. Telemetry can also measure how—and how often—certain features in the software are used. This data represents the most common use cases for end users and is a helpful metric for deciding future features to implement or focusing bug fixes in the most used features.

Telemetry can also be used for detecting and diagnosing issues within the software. When configured to intercept exceptions, telemetry can assist developers in getting ahead of the issues. By identifying issues as users experience them, the normal turnaround cycle from when a problem is identified to when it is fixed is shortened. A common issue turnaround cycle can look like this:

Compare that to a shortened issue turnaround cycle with the aid of telemetry:

The shortened cycle allows developers to be more anticipative and responsive to issues that end users find, and the result is an overall better user experience.

Telemetry does have some drawbacks. Any data collection certainly raises concerns about privacy and how the data could be abused. However, software telemetry generally is done with anonymized data to prevent tracing the data to specific users. Furthermore, the data is generally aggregated to provide useful trends and usage patterns. Telemetry of course comes with front-loaded implementation overhead and, potentially, maintenance overhead further down the road. However, these are normal overhead costs associated with any new feature. Lastly, because software telemetry is usually designed as an opt-in feature, there is always a risk that some users will not opt-in, which can result in too little data to accurately portray the entire user base. The best way to guard against this is to be transparent about how collected data is anonymized and aggregated. However, the benefits of telemetry—when properly implemented—will outweigh these drawbacks.

Software telemetry has a lot of benefits as long as the telemetry is implemented correctly. That is, telemetry needs to be done only with informed consent from the end users, and, as much as possible the data gathered should be anonymized and aggregated to prevent it from being abused if a security breach were to occur. When implemented and used properly, software telemetry can be a bridge between end users and developers, allowing developers to quickly fix bugs or provide information on which new feature to implement. In turn, this will help end users to be more productive, with new features based on their common use cases and shorter turnaround time between encountering bugs and receiving fixes for them.