Subscribe to Martyr2's Programming Underground        RSS Feed

First a Scientist, Then a Programmer.

Icon 8 Comments
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!

<Beyonce singing in the army as the theme song. Hooya>

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! :)

If you want more blog entries like this, check out the official blog over on The Coders Lexicon. There you will find more code, more guides and more resources for programmers of all skill levels!

8 Comments On This Entry

Page 1 of 1


25 April 2009 - 09:23 AM
I don't appreciate the negative connotation referred to when you voluntarily took the ASVAB in high school. Nothing wrong with taking it, nothing wrong with joining the military.


25 April 2009 - 12:23 PM

KYA, on 25 Apr, 2009 - 08:23 AM, said:

I don't appreciate the negative connotation referred to when you voluntarily took the ASVAB in high school. Nothing wrong with taking it, nothing wrong with joining the military.

All I was saying was that it was a mistake for me and what I eventually wanted to do in life. Well that and I don't appreciate the tactics used by military recruiters which I do think is a bit underhanded at times but that is beside the point I was making in the article. And I want to make it VERY VERY clear to everyone, my father is a Vietnam vet and I do know that it is a good choice for many people. Nothing wrong with it most certainly.

So quit reading into things. :P


26 April 2009 - 06:28 AM
But if he quit reading into things and taking offense at generic statements, his participation rate at DIC would plummet! ;)

Kidding KYA...a small poke at your style ;)

My own degree (well, one of them) is in math, and i spent a few years working in a physics lab after graduation before moving into programming as the resident number cruncher and algorithm optimizer. Your write-up on the scientific method is welcome indeed...although most folks not trained in it will skip the middle steps. The balanced and full approach is not something embraced by the majority of society, I'm afraid.


26 April 2009 - 08:50 AM
Nice Article :). I actually have that problem, I don't fully understand & analyze the issue before I try solving it, but I'm working on it lol.


26 April 2009 - 06:37 PM
Haha did the same thing as you. Took the asvab and was hounded. They wanted me for the physics program. To do things like nuclear engineer on a sub. Funny thing I hate physics. Once again Martyr beautiful article. Thanks.


28 April 2009 - 03:07 PM
I never had the "pleasure" of taking the ASVAB but anyway I appreciate the subject of your article, many people assume that if you're not a Natural Science graduate, then you know nothing of the scientific method. My degree is technically in Business Administration, but i have a concentration in Information Systems. People assume that since im a business major, that i have no knowledge of how to solve scientific problems...little do they know that I used to be a CS major, and have been able to apply both business and computer science knowledge to all problems i have come across


05 May 2009 - 07:47 PM
Catchy title and well written Martyr2!

By my moniker you can probably tell I'm biased - Scientific Method governs a lot of what people do around me. Having declared that, the methods can be applied to more than fixing problems - you can save time and effort avoiding re-inventing wheels (or even doubly-linked-lists) with a bit of research beforehand. And test-driven development cries out for thinking and planning testable hypotheses before you code.

With a bit of effort you can even generate innovative solutions by defining and researching exactly what you plan to accomplish. It's what drives science, why not other fields that need robust and repeatable solutions?

Again, well done M.
Happy coding.


07 May 2009 - 12:37 AM
A well written illustration on how important the scientific method is, kudos.

As far as the ASVAB, it's neither a pleasure or a pain to take, it's just a thing. The better you do on it, the more job fields it opens up, and obviously they're going to want intelligent folks working in the more technical career fields. Merely taking it is a sign to a recruiter that you may be interested in joining. They have to do their job too.

Peace out from Iraq.
Page 1 of 1