At DevTeach and the PnP Summit, there were talks on how to use instrumentation within your applications and use it to monitor the health of it throughout it's lifecycle.
At one of our past contracts, we had a problem where our users were not taking the time to test the system correctly. We then resorted to reuse the instrumentation module to track how often the individual functions of the application were used.
At first, it was only about helping them focus on the tests, or rather where they had not tested. But after a few months, it all changed; it actually became a measure of how useful the software was and what parts were being adopted.
It's motivated two things :
- When comes a time to prioritize backlog items, we can use these metrics to make sure we do things that are of the highest value for the customer, in parts of the system that we know have high traffic.
- Every time we add something to the system, we have metrics that can help us remove something else from the system. This allows the system to constantly stay the same relative size and not carry any "dead weight" into the future.
I'm not sure if Usage Coverage is a good term for these ideas, but for sure, I will be using them in future projects also.