A troubleshooting primer for software developers: The finest software engineers are those who not only write code but also test and troubleshoot it. This primer will provide a framework for best practices, regardless of whether you built the code for your present code base or inherited it.
The fallacy of “zero bug software.”
Bugs exist in every piece of software. Everyone who has ever worked in the field of software development is well aware of this particular reality. To attempt to track down and fix every single little bug that may exist in an application of any level of complexity would be financially impossible. Never mind the fact that software testing may at most only demonstrate the presence of problems and not the absence of them. Having said that, there are specific kinds of errors or software faults that need to be fixed.
Those who are usually suspected.
Errors in computer software can be attributed to a variety of different causes. The following are some of the most frequent:
- Uncertainty over the predicted conduct
- Subsystems or components that are external to the system
- Lack of sufficient testing as well as deadlines
- Programming errors
No matter who is to blame, at some point in your professional life, you will decide (or someone else will decide for you) that a problem needs to be fixed, and it won’t matter who did it. The manner in which this determination is made can vary, but in most cases, it is based on a mixture of factors including customer behavior and behaviors, loss tolerance, and loss minimization. Once the root cause of a problem has been identified, most capable software developers are able to resolve the issue. Troubleshooting, often known as debugging, is the process of determining the root cause of a problem.
The difference between troubleshooting and debugging
Debugging is a subset of troubleshooting, to put it in the simplest terms possible. It is possible to troubleshoot a problem without first debugging it, but it is impossible to debug a problem without first troubleshooting it. If you are feeling confused after reading that, you are not alone.
When compared to debugging, troubleshooting typically takes place at a higher degree of abstraction and can be applied to a wide variety of system components. It is the process of isolating the component or components of a system that is responsible for the issues that are being experienced. Troubleshooting is a process that may be applied to any system; however, this does not mean that the problem will be resolved; rather, the emphasis is placed on locating and comprehending the underlying cause of the issue.
On the other hand, debugging is a process that is unique to computer code. If you are a software engineer and have been entrusted with debugging some software module, you are expected to locate the instructions that are causing the undesirable behavior and then correct it, preferably all during the same session where it is all possible.
Documenting bugs
Making ensuring that the problem is adequately documented is the first thing that should be done when trying to troubleshoot and debug undesirable behavior in software. This will guarantee that everyone engaged has the same understanding, and it will also assist to inform subsequent steps in the process. The following are components that should always be included in a well-detailed bug report:
- Step-by-step instructions on how to recreate
- The rate of reproduction
- The anticipated outcomes
- Actual results
- The environment, together with the version
- Estimating bug fixes
As a developer, you will frequently be asked to provide an estimation of the amount of time it will take you to locate and correct a bug. Sadly, there is no correct response to this question. It is a best practice to limit the time you spend on your initial efforts to no more than four hours or a half a day. Discovering a few essential pieces of knowledge should be your primary focus throughout this first session that we’re having together.
Are you able to replicate the problem?
Do you know what the underlying problem is?
Have you zeroed in on a specific domain or component of it yet?
Congratulations are in order if you are able to locate the problem and resolve it within the allotted initial amount of time. If not, it is usually acceptable to proceed with providing stakeholders with some form of t-shirt size estimate based on your initial effort to troubleshoot the problem. You will find some general guidelines below, however, be aware that your experience may differ:
A small problem can be solved in four to eight hours.
- Medium: Requires 2-3 days to solve.
- Large: the solution could take a week or more to find.
- X-Large: In order to address this problem, you will need additional members of your team and/or careful planning.
If calculating the time required to correct bugs is such an imprecise science, at this point you might be wondering why it is even necessary to provide any kind of estimate at all. In point of fact, it all boils down to giving transparency, which serves two purposes: first, it assists in managing the expectations of stakeholders, and second, it gives product owners options in the event that it becomes obvious that doing nothing until the cure is available is not an option. It is said that Albert Einstein reportedly said, “We can not solve our problems with the same level of thought that produced them.” This is a famous quote attributed to Einstein.
Methods of debugging that have been tried and tested
Each and every one of today’s integrated development environments (IDEs) comes with an abundance of debug options. These are typically tailored to the programming environment in which you work and are designed to make your life as a developer simpler. Having said that, ensure that you don’t ignore the fundamentals.
Print stuff: a great number of different things.
The use of logs continues to be one of the most efficient methods available for problem-solving. You’d be surprised at how frequently logging reveals that the code you’ve been troubleshooting isn’t even getting called in the first place.
Check out the error message here.
You can see how people who came before you may have solved things by googling an error, but make sure you take the time to really understand the error message before you do so. The vast majority of today’s languages and frameworks will provide you with a reasonably accurate description of the error, and many of them will also offer potential solutions that are tailored to your circumstances at the same instant that the error was discovered.
Beginning with code that is known to function properly
There is a purpose behind why developers utilize source control. If you roll back to a version that is known to work and then compare the two code bases, you will be able to identify the problematic part of the code much more quickly. Even if the fault was only detected a short while ago, it is often possible to obtain some insight into the problem by reverting many versions backward, then applying updates one at a time until the undesirable behavior reappears, and repeating this process.
Execute your code after every time you make a modification.
Running the code and checking for changes in behavior as frequently as you can sound like an unpleasant process, but in all seriousness, doing so can help you avoid having to go backward in the process of troubleshooting.
Divide and conquer
It is easy to forget the fact that merely commenting out code until the problem is resolved might be a quick and dirty technique to locate the instructions that are causing the problem.
Rubber duck debugging
Software debugging may often become a team sport that demands creative thinking that goes beyond the norm. The term “rubber duck debugging” refers to one of these testing methods. It is predicated on the idea that while we are troubleshooting software, there are moments when we need to move slower in order to go faster. The steps for troubleshooting a rubber duck are explained in the following paragraphs.
Obtain a rubber duck by any means necessary: begging, borrowing, stealing, buying, fabricating, etc (bathtub variety).
Put the duck on your desk and tell it that you want to go over some code with it if that’s okay. Then put the duck on your desk.
Explain to the duck what it is that your code is trying to accomplish, and then go into a further explanation as you walk through each line of your code.
When you are trying to explain to the duck what your code is doing, at some time you will realize that what you are describing is not actually what your code is doing. The duck will look at you in an arrogant manner.
Please address the issue and thank the duck for its time.
Try not to freak out. The process of troubleshooting software, like most other things we do in life, becomes easier with expertise and practice. The most important thing is to not be hesitant to ask your colleague’s programers for assistance, to keep your approach orderly and logical, and to maintain open communication with the stakeholders throughout the entire process.
