In this lesson I want to explain why monitoring code is the only feedback you need to stop losing money in your software development projects and jumpstart growth.
Developers start to approach the idea of monitoring typically when manual processes are increasing, they no longer have time to plan, or emergencies continue to keep them glued to short-term work and no longer develop for growth.
In an already stressed situation, introducing new skills or tools into your workflow seems like a stressful goal.
But it’s the only way to evolve and restore profitability.
When code monitoring is useless
First of all, let’s clarify the fact that in general, you don’t need to monitor.
It’s not like because people mention monitoring in the most popular developer conferences, or we read that monitoring is considered a best practice today in opinionated blog posts, then every time a monitoring system is missing it means that the project is not managed correctly.
The scenario you are facing does not always require this resource; in terms of technical resources (tools, and processes) and skills.
So, you will not be motivated to spend time and money on monitoring if:
- You don’t care about the users – Maybe the users don’t pay you directly, and the decision to adopt a monitoring system remains the responsibility of the company for which you are working as a consultant and which has ownership of the client.
- The application you are working on does not generate significant revenue for the company – I see it many times. Many projects are built just to retain the customer, or for internal learning, but nevertheless, you are earning little or nothing from it.
- You are working on short-term projects – If the project you are working on has a limited duration due to the nature of the project itself, then thinking about monitoring is a waste of time.
Why instead should you monitor your application code?
Monitoring can help you solve some typical inefficiencies:
- Increase in manual processes – too much time spent on application debug, error discovery, bug fix, etc. are viewed as just a waste of time that could be allocated to thinking and coding up new features.
- Your work tends to be driven by continuous emergencies and you notice that you are no longer able to plan new developments
- You are working on a project with long term expectations that can give you the opportunity to extend your skills, processes, and toolset.
If you think monitoring will eat up even more time and money in your workday, you’re almost certainly considering the wrong monitoring strategy.
The feedback from code monitoring should help you automate your work, remove stress from daily activities and free up resources in terms of time and people needed to build and maintain softwares, so you can have more room to increase your earnings.
You need code feedback not user feedback
The key thing I would like to focus your attention on is the real role of monitoring. The ultimate goal of monitoring is to make sure that “Customer Feedback is useless”.
This statement might give some people goosebumps. Especially those who have a more managerial role, such as project managers, or product owners.
Instead it will make those who deal with software development smile with pleasure. Because when the software developers get in touch with the customer, it’s guaranteed to end in a bloodbath.
The Customer Feedback should be used only to collect information for the general progress of the project, the overall experience of using the product, or whether its design is liked or not.
When we make three hours of calls to make sure that the developer has understood that clicking on a button a red error message appears, it is obviously a waste of time.
What can the customer possibly know about the technical maintenance needed to make the application work? He knows nothing about Redis, or updating the framework, configuring servers or other technical matters.
This is the best representation of how developers tend to imagine their customers when they start using the application.
This image represents what happens when you finally leave customers alone with their new toy.
Then after a couple of days maybe you receive a phone call… It’s the customer with a couple of questions like “I didn’t quite understand, the water doesn’t come out…”
This being the case, what technical information can the customer give that helps us save time in refactoring and maintaining the codebase.
Indirect feedback
Simple: the best feedback is the data that he himself produces while using the application. Basically the feedback he doesn’t even know he’s giving.
So, The final goal of monitoring is to make developers completely autonomous for everything related to technical maintenance, and monitoring is the automatic system to achieve that goal.
I’ll give you a spoiler, and maybe even pique your curiosity a little bit, saying “No”… Logs won’t help you.
Indeed, insisting on logs because you are already used to it will only keep you away from improving your developer experience, and you will continue to be swamped by emergencies, or late in responding to customer reports.
Fix Bugs On Autopilot
When an error occurred in your application Inspector not only alerts you with a notification, but also creates a pull request on your GitHub repository to automatically fix the error.
Now you are able to release bug fixes after a few minutes the error occurred without human intervention in between. Learn more on the documentation.
Are you responsible for application development in your company? Monitor your software products with Inspector for free. You can fix bugs and bottlenecks in your code automatically, before your customers stumble onto the problem.
Register your account or learn more on the website: https://inspector.dev
