This week I want to talk about why developers should start caring about product usage analytics.
It gives you additional insights into how your code is being used, which can help you make decisions on the code to focus on vs remove. Code bases should not grow forever, this is a quick path to maintenance hell.
You should have periods where you focus on removing code and reducing code complexity.
Less code = Less maintenance cost = Less cognitive load
“But all our code is required and useful”
That’s often the reasoning I hear when I bring this up with teams I consult with. But this is not true. There are abstractions you’ve made that were never used past the one instance, there are features you’ve built that aren’t used that often by users. These unused features often require other parts of your code to be more complicated to accommodate them.
By tracking analytics you have proof that the effort of maintaining that feature brings no value to your product, your code, your users or the business.
There are 3 main reasons that I like to look at analytics as a software developer:
- Gives an indication of what code I can delete
- An indicator of what code to focus on
- An additional tool to help solve bugs
Can I delete this code?
To answer this question is one of the reasons that I look at analytics, even if it’s not a part of what my client wants me to do.
Deleting code has multiple positive benefits:
- Decrease in cognitive load: there’s less you have to keep in mind when making changes in the code base. This has a great effect on developers that might not have been a part of the code base from the beginning of the project
- Increase in delivery time: with fewer components to take into account when building new features, or improving old ones, this gives you less code to manage and test when it’s release time.
- Increase in code quality: by removing dead code you are most likely removing code that wasn’t adding to the quality of your codebase.
It’s common that developers and teams won’t want to remove features or code because “a user might need it”. In this case, given that there are objective indicators that very few users are using the features, you should at least reduce the complexity of that feature into something easy to manage and update (if it’s not already)
What code should I make more robust?
If you see a part of your codebase being used the most, it’s a very clear sign that you should spend a lot of time on that code to make it more robust. The process of doing this is simple, you simply make your code testable.
The process of making your code testable creates a more robust piece of code. To achieve this what you’ll do is:
- Ensure dependency inversion is applied
- Ensure you have good layers of separation
- Ensure you have single responsibility objects to concentrate potential failure points
The highest level of robustness you can have here is:
- Unit testing all individual pieces of code involved in this process
- Integration testing of all of the connections that make up this feature
The code with the most amount of usage should be where we focus our efforts. It should take priority over underutilized code.
Help me solve a bug
The more data we have the better chance we have of reproducing and fixing bugs.
When users experience bugs in production, we should be getting stability reports for them. These reports are often stack traces, call logs, and mostly confusing error messages that don’t really give us a clear idea of what happened.
With analytics events, you’ll be able to see exactly how the user used the app, what screen they were on, and which buttons they tapped. With all this data, reproducing a bug is much easier. You have an increased chance of finding and fixing a bug.
Getting more tools to solve bugs is always a good investment to make.
I have personally assigned weeks to remove dead code or improve highly utilized code. It’s worth the investment of spending a day or two convincing a client or your team that you should delete some code from the code base to reduce the burden of maintaining it for no benefit.
It’s a task you can do, as a developer, where you write little new code, but have a massive impact.
I hope you enjoyed this post.
Subscribe to make sure you don’t miss out on next week.
