Unless you had the bad luck of actually reading my profile, you may not know that despite being a long time programmer I also have a background in natural sciences. I was once tested by the US government in high school, of my own accord, to see my military options if I chose to go down the path. As one of my bigger life mistakes, because I did well, I was hounded by the armed forces to join for years afterwards. If my “Be all I can be” meant that the government had a new weapon or a break through new satellite, all the better for them right? But anyone who has been in the business of programming for awhile understands that it is called computer SCIENCE for a reason. Knowing how science works can ultimately lead to you being a better programmer. We will talk about this link on this episode of the Programming Underground!
Often times you hear others talk about the link between math and computing, but not always do you hear them link the idea of applying science to computing. No I am not talking about using computing in the field of science, we all know that computers help scientists everyday. I am talking about problem solving, discovery and applying scientific principles to the world of programming.
Day in and day out on the board we receive questions about code that will not work. Sure it may be a glitch in the .NET framework or how Java is understanding something we are attempting to tell it. However, the key to solving these problems can be greatly enhanced by applying logic, understanding and a standard scientific approach. One of these great tools is the Scientific Method… what science is based on.
Scientific method steps…
1. Ask a Question
2. Do Background Research
3. Construct a Hypothesis
4. Test Your Hypothesis by Doing an Experiment
5. Analyze Your Data and Draw a Conclusion
6. Communicate Your Results
Many of the toughest computing problems can be solved by applying this step by step approach. It all starts by asking a simple question about what the problem is. Before you can even think about a solution, you have to understand the problem. You have linker errors or Visual studio highlighting some line, but is that problem just a symptom or the actual problem itself? Most programmers, especially seasoned ones, typically think to themselves “oh I have run across this problem before, it is because of this and this is how you fix it.” Most of the time they are right but even the best of us can be wrong too. We tend to jump to step 3 of constructing a hypothesis for the problem before we actually know all the details of the problem at hand. This leads us to treat symptoms and patch them up quickly which leads to our bugs later on.
Once we fully understand the problem, before we go touching code, perhaps we should do some research on why the problem is happening. This is step 2 of the scientific method… do background research. Once we find the problem we often rely on our past experiences to determine the best course of action to take and implement a common solution without a second thought. Again, forming a hypothesis on limited information rather than perhaps tracing the logic back up through the code and finding the source.
So if we manage to do our research, which usually involves some Googling or checking some great resources like MSDN or well respected coding forums like DIC, we can formulate a full understanding of what is actually going on and what to do about it. Now I am not talking about applying this method to every single error, like syntax errors, but I am talking about hard to figure out logic errors. Your program may compile but just doesn’t seem to do what it was meant to do. Or perhaps it is sporadic and only errors out sometimes. But once we have identified what the problem is, and perhaps all of its symptoms, then we can formulate our attack mission and fix the error.
Our identification of the problem may be wrong (we are not perfect after all), so that is why we have to go to step 4 and test our fix once we put it in place. As programmers we never test enough and should always dedicate at least 50% of your time to testing the code you have written. As we always say, test test test. Do it in a step by step controlled manner. Put in some trace statements to see the data as it is flowing through the code. Put break points to stop execution before a crucial step, make sure the results returned from a function are EXACTLY as they should be.
As the test proceeds, analyze the data. This is step 5. Draw a conclusion based on the data analysis. Sure the data may confirm the fix is working or it may show things are still wrong. Either way you learn something. If the data is not supporting your hypothesis, then perhaps you didn’t fully understand the problem. Don’t be afraid to start over again with the steps. It is the process of refinement. The end product will always show the hard work you put into it. A program that does one thing and is solid is much better than a program that has 100 things and buggy to all hell.
Whether the results were favorable or not to your hypothesis, share your results. We helpers here at DIC love it when people have presented some problem code and show us what they have already tried and results they have gotten from those trials. Even if you don’t understand all the data, showing us the data may lead to us interpreting the data for you and giving you a better understanding of the actual problem. If you fix the problem, show us the fix as well. Let others learn from your mistakes as you will from others mistakes.
While we have experience on our side, our code solutions are not always the most solid either. Some of us give only enough to get you through the problem and trying something new. Keep this in mind and run the scientific method steps on our answers to make sure it fully works. Now of course we don’t expect you to be coming back screaming “This doesn’t work on my problem Martyr2, you dumb ass!” Because I probably will say something along the lines of “Well either you didn’t describe the problem well enough or you didn’t communicate what was actually wrong. Our code is only guidelines to follow. You are the expert on your own program.”
Applying the scientific method to problem solving in programming can yield huge results. I think we all could use a science class of some type before we venture too far into computer science. Mixing this with math, to help us understand the problem and analyze the results, and you are sure to win. Math, Science, and Computing is the tri-force of power in this world! We don’t want to think we are saving Zelda when really the problem is “Sorry Mario, but the princess is in another castle!” (And before you say, yes I know it is not Zelda in the Super Mario Brothers games I am not that dumb. Thinking it is Zelda and trying to save her in Bowser’s castle is an analogy to thinking you know the problem and finding out later it was wrong)
Thanks for reading! 🙂
