Have you read Part 12 of the Making a Side Project series?
Photo by Ray Hennessy on Unsplash
If you’ve ever built anything before you’ll have introduced some “unintended features” or bugs as we like to call them. It’s not just you, everyone does.
The term “bug” dates back over a hundred years, but has been applied to computing since the 1940’s, when a Moth was found in the Harvard Computing Laboratory, in a relay causing the Mark II to malfunction. The bug was removed and the problem fixed.
Fortunately we don’t have to go hunting for moths anymore, but the process of locating and fixing bugs can cause quite a headache.
The process of fixing bugs can be very specific to your platform, but there parts that can be applied globally, so I’ll try and address them, and get into the specifics for Deaton.
The most effective way to find bugs is to use your application. This is another reason building something you’ll use yourself, is very important.
You won’t have the money to hire a dedicated Quality Assurance (QA) person to do the testing, so you’ll be the designated person to handle all the testing. If the application is not something you’re going to use, then you’ll have to make extra time to do the necessary testing.
If you’re fortunate enough to have other people using your application, make sure you give them a clear, simple and concise way to report the error.
Having a dedicated form, may allow you to collect information relevant to the bug, such as the users operating system, browser version etc, without having to make the user submit it.
Error logging services, such as Sentry, or Bugsnag can provide another way to identify bugs. Whenever your application generates an error that results in an error page being displayed to the user, these services can automatically capture the error and alert you. So even if the user doesn’t report the error, you can be made aware of the problem, and investigate further. They can provide a summary of how often specific errors occur, allowing you to prioritize which errors to investigate.
The final thing to keep in mind when finding bugs, is being able to reproduce them. Identifying the specific criteria, which may be the user data, the user operating system, the user web browser, etc. so that you reliably recreate the problem is required before you can be confident that you can and have fixed the problem.
For visual bugs, where you don’t have access to every operating system and browser combination, you can use tools like Browser Stack, to help get access to those combinations in an affordable way. If your users are tech savvy, you may be able to get them to send you screenshots too!
In my case, I’ve used the application extensively and have made sure to be available on Twitter for anyone having issues with the software (I’ll also be adding Bugsnag soon, although I’m keeping an eye on the logs on the server in the mean time). Being able to talk to users in realtime can often make it much easier to isolate the problem the user is having.
However you identify bugs, if you don’t fix them immediately, you need a way to keep track of them. To prioritize them.
Making effective use of your time is important for a side projects, have a prioritized list of things you can work on, when you have some spare time is great!
There are many applications that are built specifically for this purpose, but if you’re working alone they can often be overkill and expensive, when a simple board in Trello or a spreadsheet (gasp) will do.
Until I start working with other people, I’m sticking with a simple Trello board to keep a list of things that need to be fixed. I can create separate lists for the type of bugs found. It could be a functionality bug or a visual bug, or break them into different parts of the website. I can also assign the bugs to part of the overall application: the marketing site; the user on-boarding; or the signed in user functionality.
This grouping, can also make it easy to fix several issues at the same time. When fixing one bug, you might see something on the same page, that can be addressed easily as well.
Without knowing the specifics of the bug, it’s hard to discuss how to fix them, but the steps are usually the same. Understand why the bug is happening, recreate the bug in your development environment. Fix the bug. Test the bug, and deploy the fix.
This is an important first step. Understanding why the bug is happening, can make it much easier to fix it. Is the bug because of a problem in your code, or perhaps something to do with the web browser (if it’s a front end issue). Is it a problem with the how the information is being pulled from the database, or how the information is being displayed. Once you know this fixing it can be much easier.
If you’re writing tests for your application, you may need to add another one to extend to the case that isn’t covered already. If you’re not writing tests, this might be a good time to start.
If you decide not too, that’s fine too, you’ll need to recreate the circumstances of the bug. This can mean loading data into your development environment, or switching to a different browser, depending on the specifics of the bug.
Now that you understand the bug and are able to recreate it, go ahead and fix it! Don’t be afraid to jump on Google, or Stack Overflow. Chances are that other people have seen the same bug that you have. They’ve spent the time to investigate and resolve the problem, so why not save yourself the same time and effort.
Automated testing can come in handy here, but it might still be too early to spend the time required for that. So go ahead and test the fix acting as the user would when the bug happened in the first place.
Depending on the bug and the fix, you may need to spend a little extra time making sure your fix didn’t break anything else. Once you’re project grows to a certain size and stability automating the testing can end up saving you a lot of time, and giving you peace of mind.
I believe in deploying to production often. As soon as a bug is fixed, I push the change to the master branch of my repository. Forge and Git work together to automatically deploy my fix to production. There are exceptions to this, but generally I prefer to deploy as soon as a fix is ready, rather than waiting for a maintenance window.
If a user was nice enough to report this bug, I try and reach out to them to let them know the bug has been fixed. Not only is this a good way to build relationships with your users, but shows you are responsive in addressing their issues.
Rinse and repeat, until you have no more bugs (or at least no more critical ones!)
