You’re a scientist, right? This means that you’ve been trained to develop and test hypotheses. That’s exactly what you do when you’re troubleshooting and debugging. That is, you need to come up with a hypothesis about the nature of the problem and then figure out how to test that hypothesis. This section will flesh out the scientific approach to finding and fixing problems with ERPLAB and EEGLAB.
The Importance of Replication
If you really want to understand a problem, you first need to make sure that you can replicate it. Does it persist after you restart Matlab? Do you get the same problem on a different computer?
Also, once you think you’ve found the solution, you should make sure that you can make the problem reappear and then disappear again. For example, imagine that a part of ERPLAB keeps crashing when you try to run a particular processing step, and you try 12 different things to make it stop crashing. And you finally get it to work after installing a new version of EEGLAB. Was the EEGLAB version really the problem? After all, you probably updated the PATH when you installed the new version of EEGLAB, so perhaps the PATH was the problem. If you want to be sure that it was a version problem, you should try going back to the previous version and seeing if ERPLAB crashes again. And then you should verify that updating the version again eliminates the crash. In experimental psychology, this is often called the ABAB experimental design.
In many cases, you don’t actually care whether you fully understand the problem, and this ABAB approach is unnecessary. Once the program is no longer crashing, you may not care what was causing the crash. But in other cases it’s really important to understand the problem. For example, imagine that you’re writing a script, and you find that you can get your script to run by sending some parameter that you don’t really understand when calling an ERPLAB function. Do you really trust that you’ve now solved the problem? In this kind of situation, the ABAB approach is usually worth the time and effort.
Start with a Literature Review
When you’re designing an ERP experiment, you already know that it’s important to read the relevant literature so that you know what has already been done in your research area and so that you can learn about useful methods for answering your scientific question. Without the necessary background knowledge, you probably won’t have a good hypothesis and probably won’t design a good experiment.
When troubleshooting or debugging, the analog is to read the documentation, do the tutorials, and scan the frequently asked questions page. If you don’t take these steps first, you’re likely to waste a lot of time pursuing bogus hypotheses about the source of the problem and trying solutions that are unlikely to work.
Carefully Observe the World and then Develop a Hypothesis
You were probably taught the “scientific method” when you were in elementary school. In the usual version, a scientist observes the world, develops a hypothesis, and then conducts an experiment to test the hypothesis. This is a gross mischaracterization of how science actually works (see, e.g., Feyerabend, 1993). However, this oversimplification is useful for troubleshooting and debugging, especially insofar as it proposes that you should carefully observe the world in the process of developing your hypothesis about the source of the problem.
In the context of software troubleshooting, this means that you should look carefully at the inputs and outputs. The main inputs are the data that are being processed and the parameters that are specified (either the settings in the GUI or the values that are being sent to a function in a script). The main outputs are the messages printed in Matlab’s command window (including but not limited to error messages) and the output data that are created. I particularly recommend taking a careful look at the parameters and the error messages (because the data are usually so complicated that you need a hypothesis before knowing what to look for).
Matlab error messages often appear to be written in a language that you don’t speak (Programmerese). But if you spend enough time looking at the messages, you may find that you know enough of the words to glean some valuable information. You may be able to get some insight by typing the key part of the message into a search engine, enclosed in double quotes and preceded by matlab. For example, if you get the error message character Vector Is Not Terminated Properly, you can type this into Google: matlab "character Vector Is Not Terminated Properly". A later section of this appendix provides more detailed information about how to decipher Matlab’s error messages.
The error message will tell you which lines of code generated the error message, both in your script and inside a function you were calling when the problem occurred. This is a major clue. You can then open the code for the function and see what was happening in that function. But keep this in mind: The actual problem in the code may have been several lines before the problem was detected, so you should look at that whole section of code.
Once you’ve done your careful observation, you should be able to develop a hypothesis.
Run Experiments and Collect New Data to Refine and Test Your Hypothesis
Now it’s time to test your hypothesis. Sometimes this is trivial: You hypothesize that you need to update your version of EEGLAB, and you then see if updating EEGLAB solves the problem. But in other cases, your hypothesis does not specify the solution, but is instead a more general hypothesis, such as which part of the code is the problem or which variable might not be set properly. In these cases, you need to figure out how to test your hypothesis.
The method for testing your hypothesis will, of course, depend on the nature of your hypothesis. However, there are two general strategies, which are analogous to recording versus manipulating brain activity. That is, you can examine the representations that your code produces (e.g., values of variables, output files) at various steps in processing, or you can attempt to modify the operation of the code (e.g., by changing the inputs or by turning off various parts of the code). I’ll say more about these options in a later section.
Science is Social!
One of the main shortcomings of the elementary school version of the scientific method is that it does not treat science as a deeply human, social activity. Much of science is driven by vanity, competition, and cooperation. I wouldn’t recommend vanity or competition when you’re troubleshooting or debugging, but cooperation is extremely valuable. More specifically, if you get stuck, get advice from other people. This could be a more experienced EEGLAB/ERPLAB/Matlab person in your lab or your department. Or it could be some stranger on the Internet. (The part of the Internet inhabited by programmers and scientists is much kinder and more helpful than most other parts.)
Often, your question has already been answered. EEGLAB has an extremely active listserv, which you can join. You can then search the archive to see if your question has already come up. ERPLAB also has a listserv with a searchable archive. If you don’t see an answer to your question, post it to the listserv.
If you’re writing a script and having a problem with a built-in Matlab function, or you’re having a problem figuring out the right syntax, you can probably find an answer on the Internet. The two best sources of answers are the resources provided by Matlab and the StackOverflow forum. I usually just type something like this into Google: Matlab “sorting a list”. I probably did that 300 times while writing this book!
Rubber Duck Debugging
If you can’t find the solution to your problem online, it might be time to ask a colleague. However, you might not have an appropriate colleague, or you might not want to bother anyone. In these cases, you can try something called rubber duck debugging. This concept comes from the observation that when you go to ask someone for help, the process of explaining the problem to that person often leads you to realize the answer. So, you really just need to try explaining the problem. Instead of taking up someone else’s time with this, you can just explain the problem to a rubber duck (Thomas & Hunt, 2019). Of course, it doesn’t need to be a rubber duck. It can be a plant, your dog, a photo of Einstein, etc. You can even try writing an email to an imaginary friend explaining the problem. The key is to describe the problem carefully in natural language. I like this approach so much that I bought rubber ducks for everyone in my lab (Figure A2.1).
Figure A2.1. Rubber ducks for debugging. They’re always happy to listen to you talk about your code, and they never judge you.
