Balancing the immediate needs of a young software project with a long-term growth strategy is a challenge.
Trade-offs are inevitable. Tough questions will crop up around which software is mission critical – and which ones can wait until later.
Error monitoring for new projects often gets overlooked. But you might find it’s more important than you think to your new project. Accurate historical reports on errors and benchmarking performance at code level will help you create an incredibly stable code base right from the start, paving the way for growth.
How error monitoring can help your project grow
Bugs, issues, faults, and defects are an unavoidable part of building excellent (and successful) software. In fact, “moving fast and breaking things” is encouraged to speed up the learning process, and is an essential concept in continuous delivery.
It’s how you choose to track, manage and resolve these “broken” things that will frame your project success, and help you build a stable code-base from the start.
But how do you go about implementing error monitoring into your new project, and which questions should you be asking as a Team Lead?
How to sell your development team on error monitoring
Stakeholders will often prefer to steam ahead building features rather than looking at tooling. So how do you convince your team that error monitoring is a critical part of building sustainable software?
As John Sonmez mentions in this article, you need to sell your ideas, and to do so, prepare as much as you can. Here are a few ways to start the conversation with your team.
- Do the research: With any new software, especially error monitoring, take the trial and request a demo to understand the concepts. Read the customer stories and get an idea of how it will integrate with your current technology stack
- Recruit key players first: You’ll need to recruit senior team members early so you can knowledge share and understand how software will work in different departments, like project management, and customer support
- Own the implementation: Be the leader and follow through. A vague suggestion to the team is not as powerful as a well-researched plan. Consider a trial in a smaller part of your project so you can experiment with workflow and critical team members
- Put forward a business case: Take a look at how many hours you already spend on reactive work (fixing errors and customer support) to build a business case for error monitoring
- Give a team demo: Once the team sees a demo of error monitoring, you’ll be able to answer any specific questions anyone has about how this will affect day to day operations
After you have made your decision to implement error monitoring as a team, you then need to take a look at what options you have going forward.
To build or to buy error monitoring?
Balancing your company’s immediate growth with long-term sustainability is challenging for any team lead. To build or to buy your error monitoring solution is one question you may have to face. Before you make the decision, here’s a quick litmus test of when each would be suitable:
When to build an in-house error monitoring solution
- Design a system that meets your exact requirements: Your company may have specialized needs to which only you can cater. If you feel you are in a unique position with specialized needs, an in-house system may be best.
- If you have complex integrations: Does your system rely on complex integrations? Communication breakdown between poorly integrated software will just slow you down. If solutions don’t have the integrations you need, it may be best to build your own.
When to buy an error monitoring solution
- Lack of developer resources: If your developers are stretched building new features for your software, you shouldn’t be building your software. Your priority is your customer experience. In the long run, bought solutions work out to be much cheaper. A younger company, say less than two years old, may spend more time and money in customer support ironing out development kinks. An error monitoring solution reduces customer support costs because you fix problems before they affect end users.
- When better technology would not give you a technical advantage: In his article Build or Buy, Chuck Cohn writes that if having superior internal technology is not a competitive advantage, there’s no need to make it yourself. He gives the example of an online store, where building amazing internal technology would probably not set you apart from competitors.
- Lack of time: Building a solution is only part of the story – you must maintain any system you create. As a startup in their first years of growth, you need to scale effectively, and your tools must scale with you. Buying software, developers do not require knowledge of how the system works internally, just how to view and update errors on your application. This lets you get started on what matters—building excellent software!
- When you need information on how users are affected by errors: Who experienced the crash, and which actions did they take that led to the error? Error monitoring solutions will give more details than you could get from building your own. Raygun Crash Reporting, for example, will show a detailed error summary including stack trace, and information on the user actions making it much easier to replicate the error.
When should you implement error monitoring?
Get error monitoring into your system early.
Errors in your application slow you down and increase churn. There’s no better time to understand how your software is affecting your lifeblood – your customers.
Accurate historical records on errors are worth their weight in gold to your team. Track an error right back to the exact commit that caused the bug in the first place. (Here’s what Raygun’s User Tracking Feature looks inside Raygun:)
The initial setup of a project is usually the time where you introduce the most errors into your software. The good news is that implementing an error monitoring tool should be quick and easy. For example with Raygun, it only takes 10 minutes to get data flowing through your dashboard with just a few lines of code.
Decide where error tracking fits in your workflow
After you have error monitoring setup on your project, you then need to integrate it into your workflow. Finding what works best for you may require a bit of tweaking however here are a few of my suggestions:
After each deployment watching errors
One thing you can start doing from day one is always watching your Raygun Crash Reporting dashboard after each deployment. Deployment tracking will ensure you that the release you just pushed out hasn’t introduced any bugs to your software.
Integrations with other tools such as Slack
Sometimes it’s unrealistic to be logging into your dashboard every time you push out an update:
ChatOps integrations enable Raygun to notify you and your team whenever an error occurs without the need to have the service open.
Assigning errors to respective developers
After an error has come to your attention, assign it to the developer responsible for that area of your product. No error is left and forgotten:
As an added benefit it will also let anyone else that looks at that issue know that someone is taking care of it so doesn’t require any further action reducing double up work.
5. Build a clear line of sight to the overall health of your software
Setting benchmarks for new projects is hard – especially when the goalposts for success move all the time.
Although goalposts move, the key performance indicators of good software don’t. Fundamental metrics like page load time errors affecting users will always be vital to the success of a software project.
So, make it easy to spot problems.
Being able to see the overall health of your software quickly is one of the main advantages of using an error monitoring tool like Raygun. A dashboard overview aggregates all of your errors into one place so you can quickly see. Watch for error spikes and fluctuations in data.
Also, you will also be able to design metrics around this information such as setting up software team KPIs.
Error monitoring for new projects will help you grow
A little time and effort spent at the beginning of your software project will save time and money in the long run. Get as much information as you can early and often so you can learn about your application, development team, and customers.